CVE-2024-3094 has shaken the Linux community with its critical supply chain compromise, affecting XZ Utils and potentially enabling unauthorized access through SSH authentication bypass. This blog post delves deep into the technical intricacies of the backdoor, its impact, affected systems, and actionable steps for security teams.
TL;DR – CVE-2024-3094
Affected products: | Fedora 40/41, Rawhide, Arch Linux, Debian unstable (Sid), Alpine edge, openSUSE Tumbleweed, openSUSE MicroOS XZ Utils Affected versions: 5.6.0, 5.6.1 |
Product category: | Remote Access Protocols |
Severity: | Critical (10.0) |
Type: | Remote Code Execution (RCE) |
Impact: | Confidentiality (H), Integrity (H), Availability (H) |
PoC: | No |
Exploit in the wild | No current indications |
CISA Catalog | Read more |
Remediation action | Revert to fixed versions |
MITRE advisory | Read more |
What is CVE-2024-3094?
With a maximum CVSS score of 10.0 and assigned to a critical supply chain compromise of XZ Utils, CVE-2024-3094 involves malicious code injected into versions 5.6.0 and 5.6.1. This backdoor manipulates the liblzma library, used for data compression, potentially leading to remote code execution (RCE) by bypassing SSH authentication.
The discovery of this backdoor was spearheaded by Microsoft engineer Andres Freund, who noticed anomalies in SSH logins on a Debian Sid system. Through a series of obfuscations and manipulation during the XZ build process, the backdoor aims to complicate analysis and execution conditions, targeting specific Linux distributions and SSH interactions.
The obfuscated malicious code is present only in the full download package and absent in the Git distribution, this is due to the absence of the M4 macro, essential for initiating the backdoor build process. Upon detection of the malicious macro, secondary artifacts from the Git repository are integrated during the build phase.
The individual behind this malicious code, identified as @JiaT75, allegedly contributed code to the oss-fuzz project, potentially aiming to thwart the detection capabilities of this fuzzer in identifying the planted backdoor within XZ Utils.
Technical analysis of CVE-2024-3094
The backdoor has been spotted from the identification of unusual behavior linked to sshd. A significant increase in CPU usage during sshd‘s login process and errors arising while utilizing the ‘Valgrind’ tool for memory debugging, were the means of identifications used by Freund.
During the XZ build process, the Build-to-Host.m4 script is executed, containing the following line:
gl_[$1]config='sed "r\n" $gl_am_configmake | eval $gl_path_map | $gl[$1]_prefix -d 2>/dev/null'
.
This line injects an obfuscated script that runs at the end of the configure script, responsible for creating the MakeFiles for xz-utils and liblzma. The identified prerequisites for exploitation indicate the attacker’s intention to add complexity to the analysis process for researchers.
The concealed code embedded within the configure script implements the backdoor exclusively based on specific conditions.
Notably, the backdoor installation within the configure script is selective, requiring the targeted OS to be x86-64 Linux and the XZ build process to be part of a Debian or RPM package build. Failure to meet this condition will result in the backdoor not being installed.
if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1); then
Upon execution of the obfuscated script, it performs various checks, including verifying if the OS is x86-64 Linux and if the build is part of a Debian or RPM package build. The XZ build process must be part of a Debian or RPM package builds (in which the backdoor won’t be installed when attempting to manually build the XZ package), which makes it more difficult to reproduce.
if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64"; then
The script aims to modify the MakeFile of liblzma to interfere with its symbol resolution during runtime, redirecting the RSA_public_decrypt@….pl symbol to malicious backdoor code.
Further analysis uncovered that during sshd’s public key authentication process, the RSA_public_decrypt@….pl function is invoked, leading to execution of the attacker’s code. This code then calls back to libcrypto for normal authentication, potentially allowing the attacker to bypass authentication under specific conditions, leading to remote code execution (RCE) on vulnerable servers.
Several runtime requirements for the exploit were also noted:
- The TERM environment variable must be unset, as it signifies the beginning of the authentication process in SSH client-server communication.
- The binary path must be /usr/sbin/sshd, indicating the malicious code’s execution when sshd uses the liblzma library.
- Environment variables LD_DEBUG and LD_PROFILE must remain unset to prevent exposure of symbol resolution interference.
- The LANG environment variable must be set, as sshd always sets it.
- The exploit detects debugging tools like rr and gdb and avoids execution, employing classic anti-debugging techniques.
Does CVE-2024-3094 affect me?
As per Repology’s indications, users running on Fedora 41, Fedora Rawhide, Debian Sid, and certain Homebrew installations running XZ versions 5.6.0 and 5.6.1 are affected by the vulnerability.
The compromised version of the XZ package is absent in other Linux distributions such as Amazon Linux, Ubuntu, RHEL, and others. However, it was detected in the Homebrew package for Mac OSX, but it has since been downgraded to a secure version.
Affected versions
OS | Package | Versions | Fix package version | Reference |
Fedora 40, Rawhide | xz | 5.6.0, 5.6.1 | Revert to 5.4.x | Advisory Advisory |
Arch Linux | xz | 5.6.0-1, 5.6.1-1 | Upgrade to 5.6.1-2 | Advisory |
Debian unstable (Sid) | xz-utils | 5.6.1 | Revert to 5.4.5 | Advisory |
RedHat | RHEL not affected | | RedHat has advised users to immediately stop any instances of Fedora 41 or Fedora Rawhide. | Advisory |
Alpine edge | xz | 5.6.1-r2 | Revert to 5.4.x 5.6.0-r2 5.6.1-r2 | Avisory |
openSUSE Tumbleweed openSUSE MicroOS | xz | 5.6.0 | Revert to 5.4.x | Advisory |
Cloud environments show limited exposure, with approximately 2% of instances running vulnerable versions.
Has CVE-2024-3094 been actively exploited in the wild?
As of March 30, there have been no observed instances of exploitation involving this backdoor code. Given that this situation is ongoing, we expect additional details to emerge in the upcoming days and weeks. We will revise this section as soon as new information becomes accessible.
How to fix CVE-2024-3094
Both XZ Utils developers and users are recommended to downgrade to verified, unaffected versions of XZ Utils, such as 5.4.6 Stable. Additionally, apart from the downgrade process, it is highly recommended that developers and users initiate an incident response procedure to assess whether they have been affected by this backdoor and to report any positive findings to organizations like the CISA. You can determine your installed version by executing the command ‘xz
-V
‘ or ‘xz --version'
.
Security teams should identify instances with vulnerable XZ versions. Additionally, organizations should follow vendor guidance to downgrade to safe XZ versions and monitor for suspicious activities. To fix, admins should follow the guidance provided in the table above for each Linux distribution.
In addition, CISA recommends downgrading to an unaffected XZ Utils version (prior to 5.6.0) and conducting thorough checks for any signs of malicious or questionable activity on systems running the affected versions.
CVE-2024-3094: What they said
Stories like these don’t come around often. That said, there have been plenty of differing points of view: