CVE-2024-3094: A Backdoor in XZ Utils Leads to Remote Code Execution

On March 29, 2024, CISA reported a critical supply chain compromise identified as CVE-2024-3094, affecting the XZ Utils data compression library [1]. This vulnerability, with a CVSS score of 10.0 (Critical), introduces a backdoor that could allow attackers to bypass SSH authentication and execute remote code on the affected systems [2]. CVE-2024-3094 vulnerability affects XZ Utils versions 5.6.0 and 5.6.1 and organizations are advised to downgrade to a secure version, such as 5.4.6, to prevent potential exploits [3].

In this blog, we explained how the XZ Utils CVE-2024-3094 exploits work and how organizations can defend against CVE-2024-3094 attacks.

CVE-2024-3094: Backdoor in XZ Utils Explained

The CVE-2024-3094 vulnerability represents a sophisticated backdoor embedded within versions 5.6.0 and 5.6.1 of the XZ Utils library, affecting the liblzma component. This backdoor, not present in the source code but introduced during the tarball distribution phase, is activated during the library's build process through an obfuscated script. This script, hidden within a test file, extracts and integrates a malicious object file into the library, modifying its behavior. 

Targeting only x86-64 Linux systems during Debian or RPM package builds, the backdoor specifically undermines the integrity of applications reliant on liblzma, most notably impacting OpenSSH when it interacts with systemd, due to libsystemd's dependency on liblzma. The backdoor's execution is conditional, designed to evade detection and analysis, and if triggered, it alters liblzma's function calls, which can potentially lead to SSH authentication bypasses or unauthorized remote code execution, posing a significant security risk to affected systems.

All Affected Products for the CVE-2024-3094 RCE Vulnerability

Here are the systems that are affected by the CVE-2024-3094 RCE vulnerability, with references to their advisories.

Proof-of-Concept (PoC) for CVE-2024-3094 Exploit in XZ Utils: How a Backdoor Leads to SSHD Compromise

Here is the full attack lifecycle of the CVE-2024-3094 exploit. 

You can also observe the two-year attack timeline from here ([9]), starting with the creation of the GitHub user Jia Tan (JiaT75) account, which was used to insert a backdoor while pretending to make legitimate contributions to multiple projects.

The attack starts by modifying the build-to-host.m4 script within the build system of the xz utility. This script is responsible for part of the build process that configures the software for the host system.

Within the build-to-host.m4 script, the following line is the vector for code injection. 

This line uses a series of piping (|) to apply a sed command and other shell evaluations to manipulate the configuration process.

Essentially, it’s set up to inject an obfuscated script that runs at the end of the configure script. This obfuscation is critical because it helps to hide the malicious intent from a cursory inspection.

As the configure script runs, it executes the previously injected obfuscated code. This code is crafted to detect if it's running in a specific environment:

• It ensures that the system is a 64-bit Linux environment (x86-64) [10].

• It checks if it is part of a Debian or RPM package build process [10].

The obfuscated code within the configure script is set to only install the backdoor under the conditions mentioned above. These checks are designed to make it difficult for researchers to reproduce the problem and, hence, analyze the backdoor, as it will not install in other environments.

If the conditions are met, the code proceeds to modify the Makefile for liblzma. The manipulation specifically targets the symbol resolution process, altering the RSA_public_decrypt@....pl symbol to point to a backdoor payload instead of the legitimate code.

When sshd (the SSH daemon) performs public key authentication, it calls the RSA_public_decrypt function. Due to the manipulation in the Makefile, this call redirects to the attacker’s code.

The malicious code attempts to extract and verify a payload embedded within the public key. After verification, this payload is passed to the system's system() call, which executes arbitrary commands, leading to remote code execution (RCE).

• Several environmental factors must be in place for the exploit to execute, such as:
  • The TERM environment variable must not be set.
  • The running binary path (argv[0]) must be /usr/sbin/sshd.
  • The LD_DEBUG and LD_PROFILE environment variables must not be set.
  • The LANG environment variable must be set.
  • Debugging tools like rr and gdb must not be detected.

If all runtime requirements are met and the payload is verified, the malicious code executes via system(), leading to RCE. The specific method of RCE, in this case, involves passing commands through the libc's system() function, which is a legitimate function commonly used to execute shell commands from C programs.