Backdoor in xz/liblzma (CVE-2024-3094)

On March 29th, Andres Freund, a Postgres developer, working at Microsoft, identified a response time while authenticating to openSSH on a Debian Sid installation that was about 500 ms longer as usual. He investigated the behaviour and concluded that liblzma, part of the xz library, was compromised by a complex backdoor injected into distribution packages during build. The versions 5.6.0 and 5.6.1 of the library are impacted. Further investigations led to the discovery of an elaborated supply chain attack scenario. The maintainers team seems to have been infiltrated over a long period of time (several years) by malevolent actors.

The story of this backdoor deserves a deep analysis which is out of topic here, but it raises a lot of questions for open-source communities and all the IT sector.

What systems are impacted?

Since the vulnerability has been detected in a relatively short time, no major distribution has already integrated those versions of the XZ library.

Only the distributions with a very fast pace of software integration (Rolling releases, testing, so-called “unstable”) had integrated the corrupted version at detection time.

As an OVHcloud customers, what are the risks?

No Linux image provided by OVHcloud to customers for automated installation are impacted. So no customer should be vulnerable to this backdoor using images provided by OVHcloud.

In some corner cases, the backdoor might have been installed on your system:

If you installed a vulnerable distribution yourself, in the timespan where the compromission was not yet discovered, outside of the OVHcloud automated installation process (for instance, Linux distribution in “rolling release” mode)

If you activated edge repositories on your system (for instance, “experimental”, “unstable” or “testing” for Debian, “edge” for Alpine, “update-proposed” for Ubuntu)

If you installed a software that is packaging the vulnerable version of the library

If you use an alternative package manager (for instance Homebrew)

The backdoor is quite complex, so even in such case, you might have deployed the corrupted version of the XZ library, without your system being actually vulnerable. Refer to your distribution/software security advisory page to get more information.

How can I check if I use a backdoored version of the library?

Check your active version of XZ library:

debian@lab:~$ strings `which xz` | grep "(XZ Utils)"
xz (XZ Utils) 5.2.5

Note: The command “xz -V” would provide a similar output. However, It is not a good practice to execute a binary that might be compromised.

Ensure the active version of XZ library is not part of the known vulnerable ones (5.6.0 and 5.6.1). If you have a compromised version of XZ, follow the security recommendations from your distribution. In some cases, a patch has been released to correct the vulnerability, in other cases, backporting to an older version of the library is recommended.