The XZ Utils Backdoor

What happened

Andres Freund found the backdoor and reported it on Openwall. He saw that logins over SSH were slower than normal. The compromise came through a contributor named Jia Tan, who had gained commit access over about two years, according to the FAQ by Sam James.

There are two injection points. The first is a script in the file m4/build-to-host.m4, which exists only in the release tarballs. It runs at the configure stage. The second is two test files in the repository, tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compressed.lzma. The build script decodes the hidden program from these files and runs it.

The hidden code hooks the ifunc resolvers in liblzma and redirects RSA_public_decrypt(). OpenSSH does not use liblzma. But many distributions patch OpenSSH to use libsystemd, and libsystemd depends on liblzma. So a patched sshd loads the bad library.

The code activates only under narrow conditions:

• x86-64 Linux with glibc
• GCC with the GNU linker
• A Debian or RPM package build
• At runtime, the process is /usr/sbin/sshd, with TERM unset and LANG set, and no debugger

Affected versions

XZ Utils and liblzma 5.6.0 and 5.6.1 are affected. Snyk reports that 5.6.0 came out on 24 February 2024 and 5.6.1 on 9 March 2024.

• Bad: 5.6.0 and 5.6.1
• Good: 5.4.6 and earlier

Snyk lists these distributions as having shipped the bad versions: Debian testing and unstable, Fedora Rawhide and Fedora 40, Kali Linux and openSUSE Tumbleweed. Most stable releases used older XZ versions and were not affected.

Indicators of compromise

• m4/build-to-host.m4 in a tarball with the serial number changed from 3 to 30 (Snyk)
• The files tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compressed.lzma, added in commits cf44e4b7 and 74b138d2 and reverted in e93e13c8
• Slower SSH logins on a system that runs a bad liblzma
• A liblzma version string of 5.6.0 or 5.6.1

How to check

Check the installed xz version.

xz --version

A result of 5.6.0 or 5.6.1 means you must act. On Debian and Ubuntu, also check the package.

dpkg -l | grep -E "xz-utils|liblzma"

On Fedora and other RPM systems, run rpm -q xz xz-libs. To check source trees, search for the changed build file.

grep -rl "build-to-host" . --include=*.m4

What to do now

1. Downgrade to xz 5.4.6 or apply the patched package from your distribution.
2. Restart sshd after you update liblzma.
3. Treat a system that ran a bad version with a reachable SSH port as possibly compromised, and review it.
4. Rebuild any container image or package that you built with the bad tarball.
5. Compare release tarballs with the tagged source. This attack lived in files that the repository did not have.

Vigilance compares the version you trust with a new one. It reports a build file that decodes a payload and runs it. See all attacks.

What Vigilance showed

Vigilance compares the version you trust with the new one and names the file that gained a new capability. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

files scanned: 21

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

CHANGED    m4/build-to-host.m4
           It now downloads from the internet. It did not before.

Sources

1. openwall.com/lists/oss-security/2024/03/29/4
2. gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
3. snyk.io/blog/the-xz-backdoor-cve-2024-3094/