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.
Some you may have missed, popular articles from the last month:
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
5 Likes, Who?
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.
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.
12 Likes, Who?
pleasereadthemanual Mar 30
Quoting: whizseOh, this might be bad. Seems like an inside job by the new'ish maintainer: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...
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.
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
9 Likes, Who?
This thing looks pretty big, methodically prepared for a long time. Possibly "state level actor".
4 Likes, Who?
pleasereadthemanual Mar 30
Quoting: pleasereadthemanualEdit: 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.Quoting: whizseOh, this might be bad. Seems like an inside job by the new'ish maintainer: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...
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.
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
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
4 Likes, Who?
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: pleasereadthemanualQuoting: 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-5005888Quoting: whizseOh, this might be bad. Seems like an inside job by the new'ish maintainer: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...
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.
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
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.
3 Likes, Who?
pleasereadthemanual Mar 30
Quoting: williamjcmMissed this comment the first time. This does not inspire confidence in me about using Arch in the future.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
3 Likes, Who?
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
0 Likes
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
2 Likes, Who?
pleasereadthemanual Mar 30
Quoting: sudoerMy 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.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...
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:
QuoteSecurityAnd for the record, I use an SSH server.
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.
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-5005888This 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
2 Likes, Who?
Patreon
PayPal
See more from me