CVE-2024-3094: 
NixOS vulnerability analysis and mitigation

Summary

A backdoor has been identified in versions 5.6.0 and 5.6.1 of XZ Utils (assigned CVE-2024-3094), which under some conditions may allow SSH authentication bypass in specific versions of certain Linux distributions. According to Wiz data, while XZ Utils itself is highly prevalent, only approximately 2% of cloud environments have instances with versions vulnerable to CVE-2024-3094. Wiz detects CVE-2024-3094 on instances scanned after 10AM UTC, March 30, 2024.

Technical details

Malicious code has been found in the XZ project's source packages, beginning with release 5.6.0. Through a series of complex obfuscations, a concealed test file within the source code is used during the liblzma compilation process to extract a precompiled object file. This file then alters particular functions within the liblzma code. Consequently, this results in a compromised liblzma library, which affects OpenSSH when it supports systemd notification. This is because libsystemd relies on lzma, and the backdoor can intercept and alter its data exchanges Specifically, certain Linux distributions use this library for SSH, and could therefore be vulnerable to remote authentication bypass.

The malicious code is obfuscated and can only be found in the complete download package, not in the Git distribution, which lacks the M4 macro, which triggers the backdoor build process. If the malicious macro is present, the second-stage artifacts found in the Git repository are injected during the build time.

The author of the malicious code (@JiaT75) reportedly also submitted code to the oss-fuzz project that may have specifically prevented this fuzzer from being able to detect the backdoor they planted in XZ Utils.

Affected products

According to Repology, there are many distributions that are potentially impacted by CVE-2024-3094, but Wiz will update this table with concrete information as vendors publicly address the vulnerability:

Ruby have announced that they themselves are not affected, and that the gem named liblzma is not affected.

Remediation and response

1. Follow the guidance provided in the table above for each Linux distribution to determine how to patch affected instances.

2. CISA have advised to downgrade any detected instances to an uncompromised XZ Utils version (earlier than 5.6.0) and to hunt for any malicious or suspicious activity on systems where affected versions have been installed.

Technical analysis of the backdoor

This section is based on analysis conducted by Andres Freund, who discovered this backdoor after noticing unusual behavior associated with sshd. He observed that sshd was consuming a surprisingly large amount of CPU during the login process. Additionally, he encountered numerous errors while using the 'Valgrind' tool for profiling and memory debugging, prompting him to investigate further.

As part of the XZ build process, the 'Build-to-Host.m4' script is executed. This script contains the following line: gl_[$1]config='sed "r\n" $gl_am_configmake | eval $gl_path_map | $gl[$1]_prefix -d 2>/dev/null', which injects an obfuscated script to be executed at the end of the configure script. This script is responsible for creating the MakeFiles for xz-utils and liblzma.

While the obfuscated script is executed, among other things it checks for two conditions: it determines if the OS is x86-64 Linux and whether it is part of a Debian or RPM package build. The script mainly aims to modify the MakeFile of liblzma in order to interfere with its symbol resolution process in runtime, particularly causing the RSA_public_decrypt@....pl symbol to point to its own malicious backdoor code.

Further analysis revealed that during the public key authentication process of sshd, the RSA_public_decrypt@....pl function gets called, causing the attacker's code to be executed. This code operates by attempting to extract a payload from the public key that is passed to it during the authentication process. This payload undergoes a series of verification steps and signature checks. If the payload successfully passes these checks, it is then transferred to the libc's system() function. This function is designed to execute the payload. Therefore, it is a Remote Code Execution (RCE), rather than authentication bypass.

Furthermore, the observed requirements for exploitation suggest that the attacker intended to complicate the analysis process for researchers.

The obfuscated code running within the configure script installs the backdoor only under certain conditions. Among several checks, the following two are noteworthy:

The targeted OS must be x86-64 Linux. If this condition is not met, the backdoor will not be installed.

if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1); then

The XZ build process must be part of a Debian or RPM package build. This makes it more difficult to reproduce, as the backdoor won't be installed when attempting to manually build the XZ package.

if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64"; then

In addition to these, several runtime requirements for the exploit have been observed:

The TERM environment variable must not be set - this variable is set in the SSH client and server communication after the authentication process has begun, and therefore if it isn't set then this means the process hasn't started yet, which is precisely the stage that the exploit targets.

The path to the currently running binary, argv[0], needs to be /usr/sbin/sshd - this means the malicious code will only run when sshd uses the libzlma library. It won't be relevant when other binaries use the infected liblzma library.

The environment variables LD_DEBUG and LD_PROFILE must not be set - to avoid exposing the process of symbol resolution interference and other linker/loader manipulations.

The LANG environment variable must be set - as sshd always sets LANG.

The exploit detects whether debugging tools such as 'rr' and 'gdb' are being used and if so it doesn't run - a classic anti-debugging technique.

References

• Wiz blog

• CISA advisory

• Debian advisory

• RedHat advisory

• Ubuntu advisory

• Homebrew advisory

• Ruby advisory

• BleepingComputer article

• Mastodon thread

• Announcement on Openwall

• xeiaso advisory

• OpenSUSE build

• Arch Linux advisory

• HelpNet Security article

• Decipher article

• Kali Linux tweet

• Hacker News thread

• Amazon advisory

• Recorded Future blog

• Ars Technica article