The xz-utils backdoor: a backdoor in the source tarballs, aimed at sshd

What it actually is

The tarballs for xz 5.6.0 and 5.6.1 contained build machinery, absent from the git repository, that injected code into liblzma. On systems where sshd is linked against liblzma through systemd, that code hooked the routine used to verify keys.

What an attacker gets: Pre-authentication remote code execution on a machine running an sshd patched to link liblzma, for whoever held the matching private key. It was a backdoor with an owner, not an open door.

When it applies to you, and when it does not

An old package version and a real exposure are different things. These are the conditions this one needs.

• Almost no stable release ever carried it. The affected versions were in rolling and testing distributions for a matter of weeks. The table below is nearly empty for exactly that reason, and that is the story rather than a gap in the data.
• The payload also required a distribution that patches sshd to link liblzma, which is a Debian and Red Hat family practice rather than an upstream one.
• It was caught by a developer investigating a half-second delay in ssh logins, not by any scanner, any signature or any audit.

Check your own server

xz --version && dpkg-query -W -f='${Version}\n' xz-utils 2>/dev/null || rpm -q xz

Any 5.6.0 or 5.6.1 build from the affected window is the one to look for. Every supported release below is far from those versions.

The part worth remembering

The useful lesson is not a version number. It is that the compromise lived in the build system rather than the source, was contributed by a trusted maintainer, and was found by somebody noticing that a login felt slow.

Fixed package version, per distribution

From each distribution’s own advisory data, asked per release. A version here is the package version that carries the fix on that release, not the upstream release number.

What SecAI has recorded about it

Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library.

Recorded from nvd. Its weakness class is CWE-506, from NVD.

• https://access.redhat.com/security/cve/CVE-2024-3094
• https://bugzilla.redhat.com/show_bug.cgi?id=2272210
• https://www.openwall.com/lists/oss-security/2024/03/29/4
• https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
• http://www.openwall.com/lists/oss-security/2024/03/29/10
• http://www.openwall.com/lists/oss-security/2024/03/29/12

Read next