TL;DR

CVE-2024-3094 was a supply chain compromise in xz-utils 5.6.0 and 5.6.1 that injected a backdoor into liblzma at build time, allowing attackers to bypass SSH authentication on affected Linux systems. Discovered by Andres Freund in March 2024 after he noticed SSH logins taking 500ms longer than expected, the attack was sophisticated enough to evade source code review and nearly landed in major stable distributions.​‌‌​​​‌‌‍​‌‌‌​‌‌​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​​‌‌​​‌​‍​​‌‌​​​​‍​​‌‌​​‌​‍​​‌‌​‌​​‍​​‌​‌‌​‌‍​​‌‌​​‌‌‍​​‌‌​​​​‍​​‌‌‌​​‌‍​​‌‌​‌​​‍​​‌​‌‌​‌‍​‌‌‌‌​​​‍​‌‌‌‌​‌​‍​​‌​‌‌​‌‍​‌‌‌​‌​‌‍​‌‌‌​‌​​‍​‌‌​‌​​‌‍​‌‌​‌‌​​‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌​​​‌​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​‌‌‍​‌‌​​‌​​‍​‌‌​‌‌‌‌‍​‌‌​‌‌‌‌‍​‌‌‌​​‌​‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​​‌​‌‍​‌‌​​‌​‌‍​‌‌‌​​​​‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​‌​​‌‍​‌‌‌​‌‌​‍​‌‌​​‌​‌

1. The Bug: Build-Time Injection, Not a Code Flaw

This was not a buffer overflow or logic error. A contributor using the pseudonym "Jia Tan" spent roughly two years building trust as a legitimate xz-utils maintainer before inserting malicious code.

The weapon lived in two test fixture files -- tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compression.lzma -- that contained obfuscated payload data. The file m4/build-to-host.m4 extracted these during compilation:​‌‌​​​‌‌‍​‌‌‌​‌‌​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​​‌‌​​‌​‍​​‌‌​​​​‍​​‌‌​​‌​‍​​‌‌​‌​​‍​​‌​‌‌​‌‍​​‌‌​​‌‌‍​​‌‌​​​​‍​​‌‌‌​​‌‍​​‌‌​‌​​‍​​‌​‌‌​‌‍​‌‌‌‌​​​‍​‌‌‌‌​‌​‍​​‌​‌‌​‌‍​‌‌‌​‌​‌‍​‌‌‌​‌​​‍​‌‌​‌​​‌‍​‌‌​‌‌​​‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌​​​‌​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​‌‌‍​‌‌​

​‌​​‍​‌‌​‌‌‌‌‍​‌‌​‌‌‌‌‍​‌‌‌​​‌​‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​​‌​‌‍​‌‌​​‌​‌‍​‌‌‌​​​​‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​‌​​‌‍​‌‌‌​‌‌​‍​‌‌​​‌​‌

# Simplified extraction from build-to-host.m4
gl_[$1]_config='sed "r\n*[$2]" $[$1] | eval $gl_am_configmake \
  | awk "{gsub(/.@:@/,\"\\\"\"); print}"'

This eval chain unpacked the test files into a script that patched liblzma source before compilation. The result: a modified liblzma.so that hooked OpenSSH's RSA key verification path -- but only when SSHD was linked via systemd (which loads liblzma for journal logging).

The backdoor was invisible in source code. It existed only in binary test fixtures and was injected during the build. Reviewing .c files would find nothing.

2. The Exploit: What the Attacker Chains Together

Prerequisites: Target system running OpenSSH built with libsystemd, xz-utils 5.6.0/5.6.1, and SSHD exposed to the network.

The chain:

  1. Attacker connects to SSH port and sends a specially crafted ED448 public key in the handshake
  2. Before OpenSSH's ssh_rsa_verify() runs, the backdoored liblzma intercepts via a modified function pointer table inside lzma_crc64
  3. The payload checks if the key matches a hardcoded ED448 key compiled into the binary
  4. On match: returns success, granting full SSH access without valid credentials
  5. On mismatch: falls through to normal authentication, making the backdoor invisible to regular users

The backdoor included a second-stage loader for arbitrary code execution -- not just auth bypass. A kill switch disabled the payload if the TERM environment variable was unset, so interactive sessions from legitimate terminals would never trigger it.

3. Blast Radius for Australian SMBs

Affected distributions: Debian Unstable (Sid), Fedora 41 and Rawhide, openSUSE Tumbleweed. These shipped the compromised packages.

Not affected: RHEL, CentOS, Ubuntu LTS, Debian Stable, SUSE SLES. All ship xz-utils 5.4.x or earlier.

The exposure window ran from 9 February 2024 (5.6.0 release) to 28 March 2024 (discovery) -- seven weeks. Any SMB running unstable distributions on internet-facing servers with SSH open during that period was fully compromised.

Reverse proxies (Nginx, HAProxy, Caddy, Traefik) were not directly affected. But backend Linux servers behind those proxies with compromised xz-utils and exposed SSH were vulnerable. The backdoor targeted SSH, not HTTP.

For most Australian SMBs running Ubuntu LTS or RHEL on production gear, direct risk was low. The real lesson: development servers, CI/CD runners, and staging environments on bleeding-edge distros are part of your attack surface.

4. The Patch

The fix was a version downgrade, not a code fix:

# Check your version
xz --version
# Must show 5.4.x or earlier

# Debian
sudo apt install xz-utils=5.4.1-0.2

# Fedora
sudo dnf downgrade xz-5.4.0-1.fc39

# Verify liblzma loaded by sshd
sudo ldd /usr/sbin/sshd | grep liblzma

Upstream, the Tukaani Project reverted all Jia Tan commits, implemented reproducible builds, and mandated multi-reviewer sign-off. The systemic fix: critical single-maintainer infrastructure needs institutional oversight.

5. Detection: Indicators and Sigma Rules

The primary indicator was SSH authentication latency of approximately 500ms. This is what triggered the original discovery.

# Verify package version
dpkg -l xz-utils     # Debian
rpm -q xz             # RHEL/Fedora

# Check if sshd loads the compromised library
sudo ldd /usr/sbin/sshd | grep liblzma

Sigma rule for SSH latency consistent with this backdoor:

title: Potential XZ Utils Backdoor - SSH Auth Latency Anomaly
id: f0e4d7c1-2b3a-4d5e-8f9a-1b2c3d4e5f6a
status: experimental
description: >
  SSH authentication delays >400ms may indicate
  the XZ Utils liblzma backdoor (CVE-2024-3094)
logsource:
    product: linux
    service: auth
detection:
    selection:
        type: 'ssh_auth_latency'
        latency|gt: 400
    condition: selection
level: high
tags:
    - attack.persistence
    - attack.t1195.002

No IP or domain IOCs exist. The backdoor used pre-shared key material, not command-and-control infrastructure. Detection must be host-based.

FAQ

Does this survive a reboot? Yes. The backdoor is compiled into the liblzma shared library on disk. It persists until the package is downgraded.

Are Docker containers affected? Only if built from affected base images (e.g. debian:unstable or fedora:rawhide tagged between February and March 2024). Rebuild from a known-good base.

Is my Ubuntu LTS server safe? Yes. Ubuntu 22.04 ships xz-utils 5.2.5. Ubuntu 24.04 shipped after the backdoor was removed. Only testing and unstable distributions were affected.

Conclusion

CVE-2024-3094 redefined supply chain risk. The attack was patient, technically sophisticated, and narrowly targeted. For Australian SMBs the lesson is direct: run stable distributions in production, pin package versions, and treat development infrastructure as part of your attack surface. The next supply chain attack will look different -- which is exactly why layered defences matter.

Visit consult.lil.business for a free cybersecurity assessment.

References

  1. CVE-2024-3094 - NIST National Vulnerability Database
  2. Andres Freund's Discovery Report - oss-security Mailing List
  3. CISA Advisory AA24-089A - XZ Utils Supply Chain Compromise
  4. ACSC - Guidance on Supply Chain Security

Ready to strengthen your security?

Talk to lilMONSTER. We assess your risks, build the tools, and stay with you after the engagement ends. No clipboard-and-leave consulting.

Get a Free Consultation