CVE-2024-3094: The xz-utils Supply Chain Backdoor Explained

Overview of CVE-2024-3094

In March 2024, a severe software supply chain attack was discovered affecting xz-utils, a widely used data compression library in Linux environments. The vulnerability, assigned CVE-2024-3094, introduced a backdoor into upstream source tarballs for versions 5.6.0 and 5.6.1 of xz-utils. This backdoor risked enabling remote code execution on affected systems, compromising the confidentiality and integrity of machines running the vulnerable library.

The xz-utils package, primarily responsible for handling LZMA (Lempel-Ziv-Markov chain algorithm) compression, is embedded in many Linux distributions and often used indirectly by other software components. The incident is notable for the subtlety and complexity of the injected malicious code, which was carefully obfuscated and embedded in the build process itself. The attack reflects a sophisticated compromise of open source software supply chains, raising significant concerns about the security of upstream components in the Linux distribution community.

For example, many package managers such as apt or yum rely on xz-utils for decompressing downloaded packages, making its integrity critical. If a backdoor is present in this library, any system action that triggers decompression can become a potential attack vector.

Technical Analysis of Backdoor

The backdoor was introduced via a combination of obfuscated scripts and malicious object files included in the source tarballs. Unlike typical source code compromises, this attack embedded a prebuilt object file disguised as test data within the repository, which was then extracted and linked during the build process. This allowed the backdoor to modify the behavior of critical cryptographic functions used by the library and, indirectly, by dependent software such as OpenSSH patched with systemd support.

The malicious code was triggered only under specific conditions to evade detection. It targeted x86-64 Linux systems built using GCC and the GNU linker, especially those built as part of Debian or RPM package builds. The activation conditions required certain environment variables to be unset or set in a particular way, such as TERM not being set and LANG being set. This selective triggering made the backdoor difficult to detect during normal testing or casual investigation.

At a technical level, the backdoor replaced ifunc (indirect function) resolvers for CRC (Cyclic Redundancy Check) functions (crc32_resolve() and crc64_resolve()) with malicious ones that performed runtime checks and memory manipulations. For example, the backdoor installed an audit hook in the dynamic linker to intercept symbol resolutions. It specifically targeted the RSA_public_decrypt symbol used by the SSH server for public key authentication.

When the SSH daemon (sshd) attempted to verify a public key during authentication, the backdoor redirected the call to its own code. This interception allowed an attacker to bypass authentication checks or execute arbitrary code remotely, effectively giving unauthorized access to the system.

Below is a simplified illustrative snippet showing how the backdoor hijacked the symbol resolution process (note: this example omits many complexities and obfuscations from the real attack):

void* malicious_RSA_public_decrypt(...) {
 if (check_attacker_key()) {
 return ALLOW_ACCESS;
 }
 return original_RSA_public_decrypt(...);
}

void install_backdoor() {
 dynamic_linker_install_audit_hook();
 redirect_symbol("RSA_public_decrypt", malicious_RSA_public_decrypt);
}

This attack used the fact that dynamic symbol resolution occurs early in process startup and that the backdoor could manipulate the Global Offset Table (GOT) before it was made read-only by the linker. The backdoor’s logic was split across obfuscated object files and shell scripts, which were embedded in the source tree as test files, further complicating detection.

As an example, a legitimate-looking test file such as test/test_compress.o might actually contain malicious binary code. During the build, scripts extracted and linked this object file into the final library, introducing the backdoor into otherwise trusted builds.

Impact on Systems and Detection Methods

This compromise primarily affected systems running xz-utils versions 5.6.0 and 5.6.1, which had been incorporated into some Linux distributions in pre-release or testing channels at the time of discovery. While affected versions were not yet widely deployed in production environments, the risk was significant due to the upstream nature of the compromise and the trust placed in the library by downstream maintainers.

One observed symptom was a slowdown in SSH login attempts due to the backdoor’s execution during public key authentication. This slowdown was caused by the backdoor’s symbol parsing and dynamic linker auditing, which added overhead to the authentication process. For instance, administrators reported that SSH logins could take several seconds longer than usual when the malicious library was in use. Interestingly, the slowdown was only observable when SSH was started under certain environment conditions, making casual detection unlikely.

Security researchers developed scripts to detect signs of infection by scanning the SSH binary and its linked libraries for the presence of the backdoor’s injected code. One such detection approach involved verifying if the RSA_public_decrypt symbol pointer had been altered from its expected location.

Below is an example detection script excerpt that checks whether the SSH binary’s RSA_public_decrypt symbol has been redirected, indicating a possible compromise:

#!/bin/bash
# Detect potential CVE-2024-3094 backdoor in sshd

SYMBOL="RSA_public_decrypt"
SSHD_BIN="/usr/sbin/sshd"

# Extract symbol address from sshd binary
SYM_ADDR=$(readelf -sW $SSHD_BIN | grep $SYMBOL | awk '{print $2}')

# Check if symbol address points outside expected range (example heuristic)
if [[ $SYM_ADDR != "expected_address_range" ]]; then
 echo "Potential backdoor detected: $SYMBOL symbol altered."
else
 echo "No alteration detected for $SYMBOL."
fi

In practical terms, administrators could run this script during incident response to quickly check for evidence of compromise, especially when investigating unexplained SSH login delays.

Administrators were urged to upgrade to patched versions of xz-utils immediately. The attack raised awareness of supply chain risks in open source projects and the need for rigorous validation of upstream sources before deployment.

Mitigation and Prevention Strategies

Addressing the CVE-2024-3094 incident involves multiple layers of response, from immediate patching to longer-term supply chain security enhancements. The following checklist summarizes essential steps for developers and security engineers managing affected or related systems:

• Upgrade Immediately: Replace xz-utils versions 5.6.0 and 5.6.1 with the latest patched releases from trusted sources. For example, use your distribution’s package manager to update the package:

sudo apt update && sudo apt install --only-upgrade xz-utils

• Verify Upstream Sources: Ensure digital signatures and checksums of upstream tarballs are validated prior to build and deployment. This practice helps confirm that downloads have not been tampered with in transit.
• Monitor SSH authentication: Look for unusual delays or anomalies in SSH logins that could indicate backdoor activity. Enabling verbose logging on the SSH server can help reveal timing anomalies.
• Scan Binaries for Symbol Hooks: Use tools like readelf and objdump to verify symbol integrity in critical binaries. For instance, running objdump -T /usr/sbin/sshd | grep RSA_public_decrypt can help confirm whether the expected function pointer has been altered.
• Implement Supply Chain Security Practices: Adopt reproducible builds, code audits, and multi-party reviews for upstream code contributions. For example, enabling reproducible builds allows independent parties to verify that the resulting binaries match the published source code.
• Enable Runtime Monitoring: Employ behavior-based anomaly detection on critical services to catch suspicious activity early. Tools like auditd can be configured to monitor for unexpected library loads or process behavior changes.

For organizations relying heavily on open source dependencies, this incident also points to the need to integrate supply chain security frameworks such as the NIST Cybersecurity Framework. Principles like continuous monitoring, incident response planning, and secure software development life cycle (SSDLC) controls can help detect and prevent similar compromises.

Architecture Diagram of CVE-2024-3094 Backdoor Attack Flow

This diagram illustrates key steps of the supply chain compromise:

• Malicious code embedded in upstream source tarballs disguised as test files
• Obfuscated object files extracted and linked during the build process
• Backdoor modifies dynamic linker behavior to intercept symbol resolution
• Hijacking of RSA_public_decrypt symbol in SSH daemon
• Remote code execution and bypass of SSH public key authentication

Key Takeaways:

• The CVE-2024-3094 backdoor exploited trusted open source distribution channels to embed complex, obfuscated malicious code in xz-utils.
• The attack targeted dynamic linking and symbol resolution mechanisms, specifically hijacking SSH authentication functions.
• Detection requires careful analysis of environment conditions, symbol tables, and runtime behavior.
• Immediate patching, upstream signature verification, and runtime monitoring are critical to mitigation.
• This incident highlights the growing importance of software supply chain security in open source projects.

For detailed technical analysis and scripts to detect the backdoor, see the original Openwall OSS Security mailing list post.

Sources and References

This article was researched using a combination of primary and supplementary sources:

Primary Source

This is the main subject of the article. The post analyzes and explains concepts from this source.

• https://www.openwall.com/lists/oss-security/2024/03/29/4