CVE-2024-3094
XZ Utils Backdoor — Supply Chain Attack
Impact: A malicious actor inserted a backdoor into XZ Utils 5.6.0 and 5.6.1 after 2+ years of building trust as a maintainer. The backdoor enables unauthorized SSH access on systems with systemd-linked sshd. CVSS 10.0 — maximum severity. Only rolling-release distributions were affected before discovery.
Step-by-Step Fix Runbook
# Check installed XZ version xz --version # Vulnerable: xz 5.6.0 or 5.6.1 # On Debian/Ubuntu dpkg -l xz-utils | grep xz-utils # On RHEL/Fedora rpm -q xz # Check linked sshd binary ldd $(which sshd) | grep liblzma # If liblzma appears AND xz is 5.6.0/5.6.1 → AFFECTED
# Ubuntu/Debian — downgrade to safe version apt-get install xz-utils=5.4.1-0.2 # Or upgrade to 5.6.2+ (patched) apt-get update && apt-get upgrade xz-utils # Fedora/RHEL — downgrade dnf downgrade xz # Verify safe version xz --version # Must NOT show 5.6.0 or 5.6.1 # Restart sshd after fix systemctl restart sshd
# Verify sshd binary is not tampered sha256sum $(which sshd) # Known good hashes for common distributions (verify against vendor advisory) # Ubuntu 24.04: check official USN-6702-1 advisory # Fedora 40: check FEDORA-2024-0f7f36c634 # Check if sshd is linked to compromised liblzma readelf -d $(which sshd) | grep liblzma # Safe systems: sshd should NOT dynamically link liblzma # Affected: shows liblzma.so dependency
# If system was running vulnerable XZ during exposure window # (March 2024 rolling releases of Fedora/Debian unstable) # Generate new SSH host keys rm /etc/ssh/ssh_host_* ssh-keygen -A # Force SSH host key verification reset on all clients # Remove old host entry from clients' known_hosts: ssh-keygen -R <your-server-hostname> # Rotate all user SSH keys that authenticated to affected server # Revoke old keys, generate new key pairs for all users
# Generate SBOM of your system syft / -o spdx-json > system-sbom.json # Scan SBOM against vulnerability databases grype sbom:system-sbom.json # Set up continuous monitoring # Alert on any new version of critical packages (xz, openssl, libssh, etc.) # Pin package versions in critical systems: # Debian: apt-mark hold xz-utils # Enable Trivy for container SBOM scanning trivy image --format spdx-json myimage:latest
# Check for unexpected network connections from sshd ss -tlnp | grep sshd netstat -tlnp | grep sshd # Check for unexpected cron jobs or systemd units crontab -l systemctl list-units --type=service | grep -v standard-services # Check recently modified system files find /usr/bin /usr/sbin /etc/ssh -newer /etc -type f 2>/dev/null # Check for unexpected SUID binaries find / -perm -4000 -type f 2>/dev/null | grep -v expected
Frequently Asked Questions
How was the XZ backdoor discovered?
The backdoor was discovered on March 29, 2024 by Andres Freund, a Microsoft engineer, while investigating unexpectedly high CPU usage in SSH logins on a Debian system. He noticed sshd was consuming ~500ms more CPU than normal on login, traced it to liblzma, and discovered the malicious code injected by a contributor named 'Jia Tan' who had been systematically building trust in the XZ Utils project for over two years.
Which Linux distributions were affected?
Only rolling-release distributions that shipped XZ 5.6.0/5.6.1 before the discovery: Fedora 40 beta and Fedora Rawhide, Debian unstable (sid) and Debian testing, Arch Linux (briefly), openSUSE Tumbleweed. Stable releases (Ubuntu LTS, Debian stable, RHEL, CentOS, Amazon Linux) were NOT affected — they shipped xz 5.4.x. macOS and Windows were not affected.
Was the backdoor ever exploited in the wild?
No confirmed exploitation was found. The backdoor was discovered remarkably quickly — within weeks of appearing in packages — before widespread distribution adoption. The attacker's timeline suggests they were still in the deployment phase when discovered. However: any system that ran vulnerable xz 5.6.0/5.6.1 with systemd-linked sshd during March 2024 should treat itself as potentially compromised and rotate credentials.
What does this mean for open source supply chain security?
CVE-2024-3094 demonstrated that long-term social engineering (2+ years of legitimate contributions) can result in a maintainer-level supply chain attack on critical open source infrastructure. Lessons: 1) Critical packages need reproducible builds. 2) Sigstore/Cosign for package signing. 3) SBOM generation and monitoring. 4) Multiple maintainer review for critical changes. 5) Behavioral testing of compiled artifacts, not just code review.