Support us on Patreon
PayPalThere'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.
Quoting: Nic264Source Archives Cannot Be Trusted.I'm not convinced this is 100% correct. It is still possible to inject malicious code whether or not you are downloading the source code directly or via an archive file.
Reproducible builds plus reproducible archives PLUS much better source code auditing is necessary. The first two alone (reproducible builds plus reproducible archives) will still net the possibility of malicious code (as an OpenSUSE dev confirmed).
Basically, to prevent this going forward, we will need a paradigm shift in source code handling and security best practices, and a LOT more eyeballs on these critical projects that have the potential to sabotage the entire ecosystem.
Last edited by sprocket on 30 March 2024 at 4:19 pm UTC
Quoting: PublicNuisanceAs soon as you make a law you have to be willing to have have people killed to enforce it. If you aren't then you can't have the law.You're an American, aren't you? Just a wild guess.
benstor214 Mar 30
Quoting: Purple Library GuyLast week, I stationed my car at a parking spot without paying for a parking ticket. I was therefore shot by a cop five minutes later.Quoting: PublicNuisanceAs soon as you make a law you have to be willing to have have people killed to enforce it. If you aren't then you can't have the law.You're an American, aren't you? Just a wild guess.
Advisory: Pay for your parking tickets!
Quoting: HamishI guess Windows 95 was a server/corporate OS for including Network Neighborhood too.
Windows 95 was the continuation of 3.11 (a tiling window-manager) on top of MS-DOS which was developed strictly for the PC in mind, as single-user, single-tasking and not network-aware. Then they started adding mutually incompatible systems on top creating the
Seeing all that, FreeBSD and Haiku make more sense. But they are not "plug'n play"-ready because they lack that manpower.
Last edited by sudoer on 30 March 2024 at 9:38 pm UTC
Quoting: sudoerGNU/Linux as it is now is a chaotic system developed mainly for server use, a victim of antagonizing corporations, each one with their "own" technologies, simply adopted by the PC, usCitation needed. And I would suspect that Stallman and Torvalds both would have objection to the statement that the GNU/Linux ecosystem is mainly for server use.
Quoting: sudoerSeeing all that, FreeBSD and Haiku make more sense.I've tried to use FreeBSD as a daily desktop driver, and it utterly fails to embrace the advances that desktop Linux has pushed over the last decade. As a server OS it is fantastic at what it does, though, provided the applications you want to use are available.
What does this have to do with the XZ tools issue? Nothing. FreeBSD used the same code as everyone else, and had to do the same audits to determine whether it affected them or not.
Quoting: sprocketQuoting: sudoerGNU/Linux as it is now is a chaotic system developed mainly for server use, a victim of antagonizing corporations, each one with their "own" technologies, simply adopted by the PC, usCitation needed. And I would suspect that Stallman and Torvalds both would have objection to the statement that the GNU/Linux ecosystem is mainly for server use.
Quoting: sudoerSeeing all that, FreeBSD and Haiku make more sense.I've tried to use FreeBSD as a daily desktop driver, and it utterly fails to embrace the advances that desktop Linux has pushed over the last decade. As a server OS it is fantastic at what it does, though, provided the applications you want to use are available.
What does this have to do with the XZ tools issue? Nothing. FreeBSD used the same code as everyone else, and had to do the same audits to determine whether it affected them or not.
Torvalds cares only for the kernel. You can find many citations easily. And having 15 (15* as a figure of speech) different compression methods to choose from, instead of one that would be properly maintained by a core team and others, as with many many other subsystems, compilers, musl vs. glibc, 15 different bootloaders, 15 different init-systems, 15 different package-managers, non FHS-respecting systems like NixOS, a dead LSB (Linux Standard Base) attempt, are not exactly what one would call "non-chaotic".
Have you looked into the kernel lately (decades)? The stuff that goes there every month is not for your PC or mine. 99% of servers worldwide are running Linux and our PCs on x86-64 with some petty CPU/GPU/RAM for office applications, multimedia and games are 2-3% of the total PC market.
Last edited by sudoer on 30 March 2024 at 10:21 pm UTC
Quoting: sudoerWindows 95 was the continuation of 3.11 (a tiling window-manager) on top of MS-DOS which was developed strictly for the PC in mind, as single-user, single-tasking and not network-aware.I don't want to argue about off topic issues in article comments but what the heck have you been smoking and where can I get some? Come on dude. Nobody here likes M$ or Windoze but let's stick with facts.
pleasereadthemanual Mar 31
Quoting: sudoerso you are saying they should use the compromised binary tarballs instead. You said it twice already.I'm not. In the interest of caution, I downgraded to an earlier version of xz. I would have felt more reassured had Arch done the same, as every other affected distribution has done. I overstated that in my initial comment, I admit. Hopefully it turns out there was no need for Arch to go further back.
What worries me is that other parts of xz may have been sabotaged. Lasse recently reverted a commit that disabled the Landdlock sandbox e.g., but this is benign: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00
Quoting: sudoerI'm not sure you understand the situation and are basically copy-pasting stuff you find elsewhere here pretending to know a thing.I'm doing my best to understand the situation. I'm not a security researcher, packager, or developer; just a user. Downgrading to an earlier version of xz sounds like the most reasonable thing to do based on what Nix and Gentoo are doing.
https://bbs.archlinux.org/viewtopic.php?pid=2160841#p2160841
pleasereadthemanual Mar 31
Quoting: pleasereadthemanualDowngrading to an earlier version of xz sounds like the most reasonable thing to do based on what Nix and Gentoo are doing.Thinking about it some more, this could also be a bad idea if you downgrade to previous Arch packages. They were built from tarballs signed by the maintainer, which could be hiding more surprises. You would want to make doubly sure that the release you are using was based on tarballs signed by Lasse and not Jia Tan.
At least with the 5.6.1-2 release, you can be assured that Arch is building the package directly from git, with no binary surprises in the tarballs.
See more from me