CVE explainer

The XZ Utils Backdoor (CVE-2024-3094)

, 4 min read

CVE-2024-3094 isn't a coding mistake. Someone put a backdoor into the release tarballs of XZ Utils, a compression library that almost every Linux distribution ships. It was found before it reached any major stable release. It was found by chance, not by any security control.

What XZ Utils is, and why sshd cared

XZ Utils provides the xz tool and the liblzma library. OpenSSH doesn't use liblzma directly. But Debian, Fedora and other distributions patch sshd to send readiness notifications to systemd, and that patch links sshd against libsystemd. libsystemd in turn depends on liblzma. So on those systems, a compromised liblzma gets loaded into the SSH daemon.

How the maintainer role was taken

The account behind it used the name Jia Tan. The public timeline runs like this:

  1. October 2021. Jia Tan sends a first patch to the xz-devel mailing list.
  2. April–June 2022. Accounts calling themselves "Jigar Kumar" and "Dennis Ens" complain on the list that the project is maintained too slowly, and push for another maintainer.
  3. Late 2022. The original maintainer, Lasse Collin, lists Jia Tan as a co-maintainer. Jia Tan starts merging commits.
  4. 24 February 2024. Jia Tan releases 5.6.0, with the backdoor.
  5. 9 March 2024. Jia Tan releases 5.6.1, with an updated backdoor.
  6. 29 March 2024. Andres Freund posts his findings to the oss-security mailing list. CISA publishes an alert the same day.

Nobody has been publicly identified as Jia Tan, and no government has formally attributed the attack.

How the backdoor was hidden

The malicious code never appeared as readable source in the Git repository. It lived in two places:

  • Test files. Two binary files under tests/files/ looked like corrupt or compressed test data. They actually carried an obfuscated payload.
  • The release tarballs. The tarballs, signed by Jia Tan, contained a modified build-to-host.m4 that the Git repository didn't. During the build, that script pulled the payload out of the test files and linked it into liblzma.

The backdoor also only activated under narrow conditions: x86-64 Linux with glibc, built as a Debian or RPM package, and running inside a process started as /usr/sbin/sshd. Anyone building from Git, or on another platform, got a clean library.

What it did

Inside sshd, the backdoor hijacked RSA_public_decrypt, a function OpenSSH uses during authentication. Researchers who took it apart found it gave remote code execution to whoever held a specific private key: a signed payload sent during the SSH handshake would run as the sshd process, before any login. NVD rates it CVSS 3.1 10.0 (critical).

How it was caught

Andres Freund, a PostgreSQL developer at Microsoft, was benchmarking on Debian unstable. He noticed that SSH logins used unusual amounts of CPU and threw valgrind errors. In his report, a login that took 0.299 seconds before took 0.807 seconds after. He traced the half-second back through sshd into liblzma and reported it.

Who was exposed

  • Affected versions: XZ Utils 5.6.0 and 5.6.1 only.
  • Debian: stable wasn't affected. Testing, unstable and experimental carried the compromised packages from 1 February 2024 until they were replaced.
  • Fedora: Rawhide got 5.6.0 or 5.6.1 with a working backdoor. Red Hat said Fedora 40 received 5.6.0 but the payload didn't activate there, and still advised downgrading.
  • RHEL: no version affected.

CISA's advice was to downgrade to an uncompromised release, such as 5.4.6.

Checking your systems

xz --version

If that prints 5.6.0 or 5.6.1, install your distribution's fixed package and treat the host as possibly compromised. If you pinned a container base image or a build image during February or March 2024, check that too.

What it means for a pipeline

  • Tarballs aren't the repository. The trigger code existed only in release archives. If you build from upstream releases, comparing the tarball against the tagged Git tree would have shown the extra build-to-host.m4.
  • Binary test fixtures can carry code. A build step that reads test data into the product is worth a second look in review.
  • Maintainer health is a supply-chain risk. A tired, lone maintainer under public pressure was the way in. Knowing which of your dependencies depend on one person is part of knowing your supply chain.
  • Performance anomalies are security signals. The only alarm was a CPU graph and a slower login. Baselines on critical paths such as SSH are worth keeping.
  • Know where each library came from. An SBOM for every build and host image makes "do we ship liblzma 5.6.x anywhere?" a query, not a search.

Sources

Related posts

Start with a $500 audit.

See exactly where you stand. Actionable findings in a week.

The full report and debrief call. Delivery in 5–7 business days.

Book a $500 Audit Hire on Upwork