CVE-2024-3094: XZ Utils Backdoor — The Supply Chain Attack That Almost Broke Linux

TL;DR

CVE-2024-3094 represents one of the most sophisticated supply chain attacks ever discovered in open source software. A threat actor spent over two years gaining maintainer trust in the XZ Utils project before inserting a carefully obfuscated backdoor into versions 5.6.0 and 5.6.1 that allowed remote code execution through SSH authentication bypasses. The backdoor was caught weeks before landing in production distributions.

Affected versions

Directly compromised:

• XZ Utils 5.6.0 (released Feb 24, 2024)
• XZ Utils 5.6.1 (released Mar 9, 2024)
• Tarball releases only (git repository was clean)

Distribution exposure:

• Fedora 40 and Rawhide (bleeding edge)
• Debian testing/unstable (sid)
• Kali Linux (rolling)
• openSUSE Tumbleweed and MicroOS
• Arch Linux (briefly)

NOT affected: Stable distributions (Ubuntu LTS, Debian stable, RHEL, CentOS, etc.) never shipped the backdoored versions. The attack targeted bleeding-edge distros to establish presence before stable releases.

Impact scope: Any system with:

• Compromised XZ versions installed
• OpenSSH compiled against liblzma
• systemd-notify support enabled in sshd
• Public SSH exposure

Root cause

This wasn't a traditional vulnerability—it was intentional malicious code inserted through social engineering and supply chain compromise:

Stage 1: Trust building (2021-2023):

• Attacker "Jia Tan" (jiat75@proton.me) began contributing legitimate patches to XZ Utils
• Created sockpuppet accounts to pressure original maintainer Lasse Collin about maintenance responsiveness
• Gradually earned commit access through consistent, high-quality contributions
• Established legitimacy over 2+ years

Stage 2: Backdoor insertion (Feb-Mar 2024):

• Malicious code hidden in binary test files within the repository (tests/files/bad-3-corrupt_lzma2.xz)
• Build system modifications in m4/build-to-host.m4 extracted and executed the backdoor during compilation
• The backdoor only activated when specific conditions were met:
  • Building from release tarball (not git)
  • Debian or RPM-based system
  • x86-64 architecture
  • GNU indirect function (IFUNC) support available

Stage 3: SSH interception:

• Modified liblzma hooked into OpenSSH through systemd notification mechanism
• When sshd loaded liblzma (via systemd), the backdoor:
  • Replaced RSA public key verification function (RSA_public_decrypt)
  • Intercepted authentication attempts
  • Checked for specially crafted authentication certificates containing encrypted commands
  • Executed arbitrary commands pre-authentication as root

Obfuscation techniques:

• Multi-stage unpacking from binary test files
• Encrypted payload (chacha20)
• Timing-based activation (delays execution)
• Anti-analysis checks (detected debuggers, sandboxes)
• Code distributed across autotools scripts, test files, and build artifacts

Exploitation primitive

The backdoor provided pre-authentication remote code execution on SSH servers:

Activation requirements:

• Target server running compromised XZ version
• OpenSSH listening on public network
• sshd compiled with systemd support and linking liblzma

Exploitation method:

1. Attacker generates special Ed448 certificate with encrypted payload
2. SSH connection initiated to target with crafted certificate
3. Before authentication completes, backdoor intercepts RSA verification
4. Payload decrypted using embedded chacha20 key
5. Commands executed as root in sshd context
6. No authentication required, no logging generated

Capabilities:

• Complete system compromise
• Stealth persistence installation
• Lateral movement to other systems
• Data exfiltration
• Supply chain poisoning of downstream systems

Detection evasion:

• No file modifications required post-compromise
• Memory-only execution possible
• Legitimate-looking SSH traffic
• No logs in auth.log or systemd journal

Discovery: The backdoor was caught by Microsoft engineer Andres Freund who noticed 500ms SSH latency increases during benchmarking and investigated, finding the malicious code through binary analysis of liblzma.

Mitigation

Immediate actions (performed in March 2024):

• XZ Utils 5.6.0 and 5.6.1 were immediately reverted by all distributions
• Downgrade to XZ Utils 5.4.x (last known-good version)
• Commands:
  • rpm -qa | grep xz or dpkg -l | grep xz to check version
  • Fedora: dnf downgrade xz
  • Debian/Ubuntu: apt install xz-utils=5.4.5-0.3
• Verify integrity: rpm -V xz or debsums xz-utils

Investigation steps:

• Review SSH access logs for anomalous pre-auth connections
• Check for unauthorized SSH keys in /root/.ssh/authorized_keys
• Scan for persistence mechanisms (cron, systemd services, LD_PRELOAD)
• Memory forensics if system was exposed while running vulnerable versions
• Network traffic analysis for C2 communications

Long-term defenses:

• Supply chain security: Enhanced review of maintainer changes, especially in core system libraries
• Build reproducibility: Verify tarball releases match git repository state
• Dependency auditing: Review all dependencies of security-critical software
• Behavioral monitoring: Alert on unusual SSH latency or pre-auth activity
• Principle of least privilege: Question why sshd needs compression libraries

Community response:

• XZ Utils maintainership transferred back to trusted maintainers
• Code audit performed on entire codebase
• Enhanced CI/CD with binary diff checks between git and tarballs
• Distributions implemented additional verification of upstream releases

Lessons: This incident highlighted critical weaknesses in open source supply chain security: lone maintainers, social engineering vectors, trust assumptions, and the difficulty of detecting sophisticated, patient attackers. It prompted industry-wide discussions about funding and supporting critical infrastructure projects.