CVE-2024-3094

Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0.
Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library.

Recent assessments:

SeanWrightFeat at April 02, 2024 6:05pm UTC reported:

The backdoor is present in versions 5.6.0 and 5.6.1.

This one has gained significant attention over the past few days. To date, there is has been observation that this backdoor was ever leveraged, and it will be unlikely to do so now, given the attention that it has received.

From a Technical perspective, this one was difficult to detect and prevent since the payload was loaded and executed in memory (as part of the SSHD process). The backdoor allowed remote code to be executed via the SSH process, making it even harder to detect.

This backdoor was only discovered by chance, by a Microsoft developer at Microsoft, Andres Freund. Andres was investigating a performance issue in SSH (which was caused by the backdoor), and then stumbled upon the backdoor. Details of which can be found on their post: <https://www.openwall.com/lists/oss-security/2024/03/29/4&gt;. Also worth noting that the backdoor was not introduced into the code of xz, but rather the binaries. This means if you built the binaries from source, you did not include the backdoor.

noraj at April 03, 2024 8:52am UTC reported:

The backdoor is present in versions 5.6.0 and 5.6.1.

This one has gained significant attention over the past few days. To date, there is has been observation that this backdoor was ever leveraged, and it will be unlikely to do so now, given the attention that it has received.

From a Technical perspective, this one was difficult to detect and prevent since the payload was loaded and executed in memory (as part of the SSHD process). The backdoor allowed remote code to be executed via the SSH process, making it even harder to detect.

This backdoor was only discovered by chance, by a Microsoft developer at Microsoft, Andres Freund. Andres was investigating a performance issue in SSH (which was caused by the backdoor), and then stumbled upon the backdoor. Details of which can be found on their post: <https://www.openwall.com/lists/oss-security/2024/03/29/4&gt;. Also worth noting that the backdoor was not introduced into the code of xz, but rather the binaries. This means if you built the binaries from source, you did not include the backdoor.

ccondon-r7 at April 03, 2024 7:28pm UTC reported:

The backdoor is present in versions 5.6.0 and 5.6.1.

This one has gained significant attention over the past few days. To date, there is has been observation that this backdoor was ever leveraged, and it will be unlikely to do so now, given the attention that it has received.

From a Technical perspective, this one was difficult to detect and prevent since the payload was loaded and executed in memory (as part of the SSHD process). The backdoor allowed remote code to be executed via the SSH process, making it even harder to detect.

This backdoor was only discovered by chance, by a Microsoft developer at Microsoft, Andres Freund. Andres was investigating a performance issue in SSH (which was caused by the backdoor), and then stumbled upon the backdoor. Details of which can be found on their post: <https://www.openwall.com/lists/oss-security/2024/03/29/4&gt;. Also worth noting that the backdoor was not introduced into the code of xz, but rather the binaries. This means if you built the binaries from source, you did not include the backdoor.

Assessed Attacker Value: 5
Assessed Attacker Value: 5Assessed Attacker Value: 1