Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.

XZ tools and libraries compromised with a critical issue

By - | Views: 64,549

There's been an urgent security bulletin sent out in a few places today in the Linux sphere that relates to the XZ tools and libraries with liblzma, as certain version have been compromised.

From the OpenWall security list:

After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind errors) I figured out the answer:

The upstream xz repository and the xz tarballs have been backdoored.

At first I thought this was a compromise of debian's package, but it turns out to be upstream.

From what they say the issue is present in version 5.6.0 and 5.6.1 of the libraries.

This has led to Red Hat putting up an urgent blog post on the matter, noting that so far Fedora Linux 40 is okay but you should "immediately stop usage of any Fedora Rawhide instances" as they were updated but they're going to be reverting to an older version.

For those not clear on what it is, as Red Hat noted: "xz is a general purpose data compression format present in nearly every Linux distribution, both community projects and commercial product distributions. Essentially, it helps compress (and then decompress) large file formats into smaller, more manageable sizes for sharing via file transfers".

Red Hat also noted the "malicious build interferes with authentication in sshd via systemd" and so "Under the right circumstances this interference could potentially enable a malicious actor to break sshd authentication and gain unauthorized access to the entire system remotely".

Debian also has a security advisory up on it noting that "no Debian stable versions are known to be affected" but the compromised packages were part of "Debian testing, unstable and experimental distributions" which they have reverted as well.

On the Ubuntu side they have a Discourse forum post noting the affected package was removed from "Ubuntu 24.04 LTS (Noble Numbat) proposed builds" and they're continuing to investigate.

It has been assigned as CVE-2024-3094 noting it is a critical issue.

So you'll want to ensure any XZ packages are not at version 5.6.0 or 5.6.1, and check the news directly from your chosen distribution for updates on it.


Update 02/04/24: the Binarly Research Team announced a new free tool to scan an ELF binary for XZ backdoor detection.

Article taken from GamingOnLinux.com.
Tags: Security, Misc
24 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
59 comments
Page: «2/6»
  Go to:

ShabbyX Mar 29
Quoting: dibzMight be fighting words for some, but this makes me glad I'm a bit old hat and generally not a fan of rolling distributions, which is who this mainly applies to. This attack entered the effected package only a couple months ago for pete's sake.

12~6 years ago I used to upgrade to the latest Ubuntu version every 6 months, thinking Debian is unthinkable because 2 years between updates?!!1!1!

Then snaps happened and I put off upgrades since Ubuntu 2018, thinking I gotta change distros. Fast forward to 2024, I realized I hadn't upgraded my OS for 6 years*! Debian's 2 year cycle didn't seem so bad now :)

* Totally unrelated to my first kid being 6 years old now :-"


Last edited by ShabbyX on 30 March 2024 at 4:25 am UTC
whizse Mar 29
View PC info
  • Supporter
Oh, this might be bad. Seems like an inside job by the new'ish maintainer:

https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

If so, someone needs to go through xz-utils with a fine toothed comb.
Quoting: whizseOh, this might be bad. Seems like an inside job by the new'ish maintainer:

https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

If so, someone needs to go through xz-utils with a fine toothed comb.
So it would seem that this new maintainer has been trying to gain control of XZ since 2021, and has had control of it since 2023. That's quite concerning and surprising. It seems unusual for bad actors to try to gain control of the supply chain long-term. Older XZ releases might have other unreported vulnerabilities even on stable distributions...

This maintainer has at least 750 commits to his name: https://hachyderm.io/@joeyh/112180715824680521

But to quote Glyph:

QuoteI really hope that this causes an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever. I want everyone who has an open source dependency to read this message https://www.mail-archive.com/[email protected]/msg00567.html


Last edited by pleasereadthemanual on 30 March 2024 at 12:42 am UTC
sudoer Mar 30
This thing looks pretty big, methodically prepared for a long time. Possibly "state level actor".
Quoting: pleasereadthemanual
Quoting: whizseOh, this might be bad. Seems like an inside job by the new'ish maintainer:

https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

If so, someone needs to go through xz-utils with a fine toothed comb.
So it would seem that this new maintainer has been trying to gain control of XZ since 2021, and has had control of it since 2023. That's quite concerning and surprising. It seems unusual for bad actors to try to gain control of the supply chain long-term. Older XZ releases might have other unreported vulnerabilities even on stable distributions...

This maintainer has at least 750 commits to his name: https://hachyderm.io/@joeyh/112180715824680521

But to quote Glyph:

QuoteI really hope that this causes an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever. I want everyone who has an open source dependency to read this message https://www.mail-archive.com/[email protected]/msg00567.html
Edit: This comment originally linked to another comment about another related developer. But there's good reason to believe that this supply chain attack is limited to xz for now.

A malicious patch series almost got into the kernel, too.

Github has removed the xz repository entirely.


Last edited by pleasereadthemanual on 30 March 2024 at 9:49 am UTC
bonkmaykr Mar 30
Quoting: whizseOh, this might be bad. Seems like an inside job by the new'ish maintainer:

https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

If so, someone needs to go through xz-utils with a fine toothed comb.
Quoting: pleasereadthemanual
Quoting: pleasereadthemanual
Quoting: whizseOh, this might be bad. Seems like an inside job by the new'ish maintainer:

https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

If so, someone needs to go through xz-utils with a fine toothed comb.
So it would seem that this new maintainer has been trying to gain control of XZ since 2021, and has had control of it since 2023. That's quite concerning and surprising. It seems unusual for bad actors to try to gain control of the supply chain long-term. Older XZ releases might have other unreported vulnerabilities even on stable distributions...

This maintainer has at least 750 commits to his name: https://hachyderm.io/@joeyh/112180715824680521

But to quote Glyph:

QuoteI really hope that this causes an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever. I want everyone who has an open source dependency to read this message https://www.mail-archive.com/[email protected]/msg00567.html
It gets a lot worse. This bad actor has made contributions all over core Linux projects like systemd: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5005888#gistcomment-5005888

A malicious patch series almost got into the kernel, too.

Github has removed the xz repository entirely.

Jesus, if that's what it's come down to...

Gentoo users probably having a field day laughing at us right now compiling all their stuff from scratch.
Quoting: williamjcm
QuoteSo you'll want to ensure any XZ packages are not at version 5.6.0 or 5.6.1, and check the news directly from your chosen distribution for updates on it.

Arch has repackaged 5.6.1, using a repo clone instead of the compromised tarballs: https://security.archlinux.org/ASA-202403-1
https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad
Missed this comment the first time. This does not inspire confidence in me about using Arch in the future.
sudoer Mar 30
Quoting: pleasereadthemanualMissed this comment the first time. This does not inspire confidence in me about using Arch in the future.

huh? maybe you missed that "The malicious code path does not exist in the arch version of sshd, as it does not link to liblzma" too. Also, how many "home" users use a ssh server...

The main problem is basically that we are using a server OS that has gotten too big, basically chaotic thus uncontrollable, when all "home" users needed was something like FreeBSD which doesn't use thousand of different tools and is being developed and curated as a whole. An OS like haiku for example, multi-user sure, multi-threaded sure, memory-protected sure, "network-aware" sure, but not including ssh and other server/corporate functionality.
A FLOSS OS just for the PC.


Last edited by sudoer on 30 March 2024 at 9:42 am UTC
kaktuspalme Mar 30
Quoting: bonkmaykrGentoo users probably having a field day laughing at us right now compiling all their stuff from scratch.

Doesn't change anything if the sources are get from the tarball.


Last edited by kaktuspalme on 30 March 2024 at 9:46 am UTC
Quoting: sudoer
Quoting: pleasereadthemanualMissed this comment the first time. This does not inspire confidence in me about using Arch in the future.

huh? maybe you missed that "The malicious code path does not exist in the arch version of sshd, as it does not link to liblzma" too. Also, how many "home" users use a ssh server...
My issue is that Arch, unlike openSUSE, Gentoo, Nix, Fedora Rawhide, Fedora 40/41, Kali Linux, and Homebrew, are continuing to use the 5.6.1 release, just pulling directly from Github and not the binary tarballs which were compromised. All of these other distributions have downgraded to 5.4.6. Gentoo has gone so far as to downgrade to 5.4.2, which is the last release signed by the previous maintainer.

That's because none of these distributions have fully analyzed the source for xz, and out of concern that there is more malware hiding in the weeds, they've gone further back.

Also, the Arch Linux news post recommended using ldd on the xz executable which was known to be malicious in at least one way. You should never do this. Read the man page for ldd for why:

QuoteSecurity
Be aware that in some circumstances (e.g., where the program specifies an ELF interpreter other than ld-linux.so), some versions of ldd may attempt to obtain the dependency information by attempting
to directly execute the program, which may lead to the execution of whatever code is defined in the program's ELF interpreter, and perhaps to execution of the program itself. (Before glibc 2.27, the
upstream ldd implementation did this for example, although most distributions provided a modified version that did not.)

Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code. A safer alternative when dealing with untrusted executables is:

$ objdump -p /path/to/program | grep NEEDED

Note, however, that this alternative shows only the direct dependencies of the executable, while ldd shows the entire dependency tree of the executable.
And for the record, I use an SSH server.

I don't understand why Arch is choosing to trust that very recent versions of xz are not compromised without much further investigation.

That being said, this should probably be disregarded:

Quoting: pleasereadthemanualIt gets a lot worse. This bad actor has made contributions all over core Linux projects like systemd: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5005888#gistcomment-5005888
This developer is significantly more trustworthy. So at this stage, it's hopefully only xz that's compromised.

Also worth mentioning that this impacted Homebrew for macOS users.


Last edited by pleasereadthemanual on 30 March 2024 at 9:49 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.