On March 29, 2024, a shocking security flaw was discovered in one of Linux’s key libraries, xz/liblzma, tracked as CVE-2024-3094.
Malicious code hidden inside xz version 5.6. and later versions gave attackers a way to compromise Linux systems, including SSH authentication on some major distributions. In this article, we’ll walk you through this vulnerability in simple language, show you some of the malicious code, explain how it worked, and give you links for more reading.
🚨 What Happened?
Someone managed to inject malicious code into the official xz source tarballs. This code was *very* well hidden and used the build process to sneak in a malicious pre-built object file. When built, xz/liblzma became compromised, and any software (like SSHd) using liblzma could be “backdoored.” This is a classic example of a supply chain attack.
Key Points
- Hidden in Source: The code was not visible in the main source, but it was hiding in test scripts and obfuscated files.
- Runs During Build: The build process extracted a disguised object file, which was then used to patch liblzma internals.
Obfuscated code in build-to-host.m4 and custom build scripts.
- A disguised tar file named test/test.c that was actually an object file.
- Makefile.am and configure.ac were changed to extract and link this hidden object file into liblzma.
Here’s what the malicious code basically did (simplified)
# During the build, extract a payload from the disguised test file:
objcopy -O binary -j .payload test/test.c payload.o
# Then link this payload into the main liblzma build
# This was hidden in the Automake scripts
The build configuration (build-to-host.m4) had sneaky logic like
if test "x$enable_backdoor" = "xyes"; then
$CC -c test/test.c -o payload.o
$AR rcs liblzma.a payload.o
fi
But real exploitation used more complex and hard-to-spot methods.
🦠 What Did the Malicious Code Do?
The hidden payload modified internal liblzma functions (used for xz compression and decompression). This changed how liblzma behaved.
In the case of OpenSSH on affected systems
- When an attacker connected with a special key, the *backdoored* liblzma could let them bypass authentication.
🎯 Who Was Affected?
- Linux distributions that took their xz/liblzma libraries straight from the upstream tarballs between 5.6. and 5.6.1.
- Specifically, some beta or development branches. Fedora Rawhide and Fedora 40 pre-release were notable examples.
- Debian, Ubuntu (stable), Red Hat were mostly safe because they didn’t ship these versions as stable packages.
🔗 Key References
- GitHub incident report by Andres Freund (the first discoverer)
- NIST NVD CVE-2024-3094 page
- FreeDesktop.org bug tracker discussion
- XKCD comic explaining supply chain attacks… in spirit
Example pseudo-attack
# From attacker machine:
ssh -i backdoor_key root@target
# No password is asked!
IMPORTANT: You had to be running the compromised liblzma AND a version of OpenSSH linked to it, as was the case on Fedora Rawhide Linux.
xz --version
`
If it says 5.6. or 5.6.1, check your distribution’s security advisory right away!
- Update liblzma/xz immediately to a safe version (5.4.x or patched).
- Rebuild any applications that dynamically link against liblzma after fixing the vulnerable library.
---
## 🚨 Lessons Learned
- Supply chain attacks are real. You can trust “official” sources and still get bitten.
- Review, review, review: Watch for even small code changes in critical libraries.
- Isolation helps: Use separate build and test environments.
---
## ✅ Conclusion
The xz backdoor (CVE-2024-3094) is among the most dangerous and advanced Linux supply chain attacks to date.
It affected only a narrow scope of users, but if it had gone undetected, it could have been disastrous.
Stay safe: always watch your dependencies, keep your systems updated, and follow security advisories!
---
*This post is exclusive and written in clear, simple language to help everyone understand one of the most notorious Linux vulnerabilities of 2024.*
Timeline
Published on: 03/29/2024 17:15:21 UTC
Last modified on: 03/31/2024 01:15:47 UTC