xz Backdoor CVE-2024-3094

By Omkhar Arasaratnam, General Manager, OpenSSF; Bennett Pursell, Ecosystem Strategist, OpenSSF; Harry Toor, Chief of Staff, OpenSSF; Christopher “CRob” Robinson, OpenSSF TAC Chair & Director of Security Communications, Intel

CVE-2024-3094 documents a backdoor in the xz package. This backdoor was inserted by an actor with the intent to include an obfuscated backdoor into the software. While the motivation behind this backdoor remains unknown, the intent was to compromise specific distributions, as the backdoors were only applied to DEB or RPM packages for the x86-64 architecture built with gcc and the gnu linker.

The Vulnerability in XZ Utils

A backdoor in upstream xz/liblzma was announced on the oss-security mailing list regarding the xz compression tools and libraries. Specifically, the issue with the xz libraries are with version 5.6.0 and 5.6.1, and users are urged to immediately stop usage and downgrade to xz-5.4.x.

This vulnerability in XZ Utils – the XZ format compression utilities included in most Linux distributions – may “enable a malicious actor to break sshd authentication and gain unauthorized access to the entire system remotely,” Red Hat warns. However, they note “Luckily xz 5.6.0 and 5.6.1 have not yet widely been integrated by Linux distributions, and where they have, mostly in pre-release versions.”

The author intentionally obfuscated the backdoor in distribution tarballs, intended for Linux distributions to use for building their packages. When the xz build system is instructed to create an RPM or DEB for the x86-64 architecture using gcc and gnu linker, the backdoor is included in the liblzma as part of the build process. This backdoor is then shipped as part of the binary within the RPM or DEB. 

Other distributions are also likely affected by this if bleeding-edge versions are used. SUSE has published a downgrade procedure for those running openSUSE. Debian says that stable versions are unaffected, but those using the testing, unstable, and experimental distributions may be affected. 

Threats in the Open Source Software Supply Chain

Threats to open source software can affect any part of the supply chain. In this case, a nefarious or compromised maintainer appears to have inserted malicious code into the package. The nature of open source software allowed this vulnerability to be discovered, reported, and addressed in a short period of time due to the diligence and oversight of the community. 

Thankfully, the number of systems affected by this backdoor is relatively low as this version of xz was not broadly distributed by distros and was caught quickly. The thoughtful, paced release process of first introducing new packages to “experimental” releases, prior to rolling them into “stable” releases served the community well by keeping the compromised packages contained to a narrow distribution. Cooperation between the distributions through venues such as the oss-security and distros mailing lists allowed quick and decisive resolution to this compromise.

Situations like this remind us all that we need to remain vigilant within the open source software ecosystem. Open source is about well-intentioned humans donating their time and talents to help solve problems, and sadly this can be compromised. As we all learn more details about the anatomy of this attack and the upstream and downstream response, it will give us time to reflect upon how we all can do more to secure open source software and help maintainers and consumers alike.

The OpenSSF encourages everyone to verify that they are not using a vulnerable version of this software, especially if using one of the experimental or bleeding edge distributions or repositories.

React Faster in the Next Supply Chain Compromise

Writing and maintaining open source software is a very hard and often thankless task. It is equally hard being downstream from that act of creation as an enterprise operator. Good cybersecurity is equal parts prevention and cure. Therefore, OpenSSF encourages our community of security experts, maintainers, developers, and open source advocates to join in the conversation in the coming days and weeks so that we can start to collaborate on how to better assist ALL participants within our open source ecosystem.

One way to participate is during the upcoming SOSS Community Day North America event on April 15, where we will conduct a tabletop exercise that simulates an open source supply chain attack. The goal of this exercise is to provide the community with guidance on how to react when the next supply chain compromise occurs. We hope you’ll join us!