Red Hat has alerted about CVE-2024-3094, a critical backdoor in XZ tools, affecting Linux distros. Here's everything you need to know.
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.
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 | |
Remediation action | Revert to fixed versions |
MITRE advisory |
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.
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:
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.
OS | Package | Versions | Fix package version | Reference |
Fedora 40, Rawhide | xz | 5.6.0, 5.6.1 | Revert to 5.4.x | |
Arch Linux | xz | 5.6.0-1, 5.6.1-1 | Upgrade to 5.6.1-2 | |
Debian unstable (Sid) | xz-utils | 5.6.1 | Revert to 5.4.5 | |
RedHat | RHEL not affected |
| RedHat has advised users to immediately stop any instances of Fedora 41 or Fedora Rawhide. | |
Alpine edge | xz | 5.6.1-r2 | Revert to 5.4.x 5.6.0-r2 5.6.1-r2 | |
openSUSE Tumbleweed | xz | 5.6.0 | Revert to 5.4.x |
Cloud environments show limited exposure, with approximately 2% of instances running vulnerable versions.
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.
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.
Stories like these don’t come around often. That said, there have been plenty of differing points of view:
Each new vulnerability is a reminder of where we stand and what we need to do better. Check out the following resources to help you maintain cyber hygiene and stay ahead of the threat actors: