Yesterday, Red Hat Information Risk and Security and Red Hat Product Security learned that the latest versions of the “xz” tools and libraries containmalicious codethat appears to be intended to allow unauthorized access. Specifically, this code is present in versions 5.6.0 and 5.6.1 of the libraries. Fedora Linux 40 users may have received version 5.6.0, depending on the timing of system updates. Fedora Rawhide users may have received version 5.6.0 or 5.6.1. This vulnerability was assigned CVE-2024-3094.
PLEASE IMMEDIATELY STOP USAGE OF ANY FEDORA RAWHIDE INSTANCES for work or personal activity. Fedora Rawhide will be reverted to xz-5.4.x shortly, and once that is done, Fedora Rawhide instances can safely be redeployed. Note that Fedora Rawhide is the development distribution of Fedora Linux, and serves as the basis for future Fedora Linux builds (in this case, the yet-to-be-released Fedora Linux 41).
At this time the Fedora Linux 40 builds have not been shown to be compromised. We believe the malicious code injection did not take effect in these builds. However, Fedora Linux 40 users should still downgrade to a 5.4 build to be safe. An update that reverts xz to 5.4.x has recently been published and is becoming available to Fedora Linux 40 users through the normal update system. Concerned users can force the update by following the instructions at FEDORA-2024-d02c7bb266 — unspecified update for perl-Compress-Raw-Lzma and xz — Fedora Updates System.
Other leading edge, or rolling distro are probably/possibly affected as well. If you use OpenSUSE Tumbleweed, Arch, etc, you should check to see if you are affected.
I think it’s important to note that the only reason we can safely avoid this issue today is because Linux is open-source. Some non-security developer doing some non-security-related benchmarks led him down a rabbit hole of code checks which would have only been possible with an open-source codebase like this.
The simple truth of the matter is that had a backdoor like this (likely of nation-state origin tbh) been added to Windows, macOS, iOS, etc. it would never have been caught in this manner. And no, it is not “easier” to add a backdoor like this to an open source project: If this person could have infiltrated an open-source project for 2+ years just to add a backdoor now, they could have just as easily got hired at Microsoft/Apple/etc. to do the same thing. Intelligence agencies can and will do all of those things because they can afford to make long-term plays like that: You bet this is happening with all systems, and yet it was uncovered here
Obviously Linux teams will need to evaluate why this code made it this far past regular checks, etc., but I’d consider this discovery to be a pretty big W for the Linux/open-source community overall.
As some articles mentioned: if the backdoor devs hadn’t been sloppy implementing their script (the dev that found it noticed his SSH connections were unusually slow) it would have probably gone unnoticed for quite a bit longer.
It is also scary even though it’s not this person submitting it since it implies they’ve already been working on the Linux kernel code as a trusted maintainer too. It’s not listing them as a new maintainer but rather documenting that they are already one.
From what I’ve read it seems that the version found to be malicious was present in at least these distros:
Fedora
Rawhide
41
40
OpenSUSE Tumbleweed
Arch
Debian
Unstable/Sid
Testing
Ubuntu 24.04 (pre-release)
NixOS (unstable)
All of these distros did have, at least briefly, the version of XZ which was found to be malicious. But it is unclear if every distro on the list shipped aversion that was exploitable/vulnerable, the belief is that some distros that had the version found to be malicious were not affected by it. (I don’t quite understand what is meant by that, but that is what is being reported).
Only distros which patched sshd to add systemd support were impacted, so Arch was not impacted by this specific SSH vulnerability, even though they shipped the compromised package.
I suppose it’s possible Tumbleweed did as well. The other distributions are frozen so it would have only been in unstable/not final releases. (Fedora 40 for example isn’t currently yet released).
That we know of. This maintainer is responsible for over 750 commits in a timeframe measured in years. There could be other backdoors or malicious code hiding in xz, though not necessarily related to SSH.
To be clear, what Arch has done is not downgrade to a known previously good version before the bad actor took over a year ago. They have simply decided to build xz 5.6.1 directly from the github repository instead of using the maliciously-prepared tarballs: upgpkg: 5.6.1-2 (88138575) · Commits · Arch Linux / Packaging / Packages / xz · GitLab
True, but it is in beta/soon to be released. Many people in the Fedora community are already using it (myself included). Likewise, with Debian, while testing and unstable are technically development branches, tons of desktop users and hobbyists prefer those versions to stable.
@dngray as far as actually released releases go, Kali Linux, openSUSE Tumbleweed, and Arch are the three I know of so far that shipped the backdoored package, and the first two also shipped impacted SSH packages.
But yes plenty of people use Debian Sid, and probably many use Fedora 40 too given the official beta release.
The author of the ‘xz’ backdoor commit history and activity shows that they kept office hours mostly. Mon-Fri, every other Saturday, I would imagine some of these would correlate with public holidays as this was clearly not a hobbyist. JiaT75 (Jia Tan) · GitHub
On the one hand, it is harder because if you are sloppy, people will find it, like they did here. But on the other, many open source projects have sloppy QA (if they even have it) that just waves through changes if it doesn’t break the build, which kinda makes it easier if you’re smart about it.
as far as actually released releases go, Kali Linux, openSUSE Tumbleweed, and Arch are the three I know of so far that shipped the backdoored package, and the first two also shipped impacted SSH packages
dodged that bullet.