Fedora 40+ / Rawhide,
Debian Sid,
openSUSE Tumbleweed
Arch
MacOS using homebrew (see below)
tl;dr
Apparently, there has been some pretty nasty code that made it into xz 5.6.0 and 5.6.1. I’d recommend reading the vulnerability reports below and doing your own research, but it sounds like to me, that systems with systemd and xz version 5.6.0 or 5.6.1 are exposed to an ssh authentication exploit.
You can check your version of xz by running:
xz -V
MacOS Homebrew @vivante mentions this below for macOS
Homebrew upgrade on MacOS rolled back liblzma and XZ Utils to 5.4.6.
Apparently it is not exploitable but do your rollback just in case.
Everything I know about the XZ backdoor <— detailed analysis of JiaTan contribution history (suspected sockpuppets, stirring un undermannet project to get access rights)
Apparently part of the backdoor was in the tarball only but not the source on GitHub. All the more reason for OSS build systems to move away from downloading tarballs and use shallow clones instead.
I think this has highlighted the need for development of some additional automated testing: testing to verify that there is no addiotnal functionality that was not accounted for.
e.g., maybe automated tests comparing open ports before/after, looking at libraries loaded before/after, etc.
because clearly, relying on the “many eyes, it’s OPEN SOURCE” stuff is just inadequate.
But I was more referring to the distributions and those responsible for incorporating it.
I’ve had the feeling for some years now that the linux platform is ripe to get fucked over by people like this because whilst it is open source and everyone CAN audit it… nobody (not literally nobody, but very, very few - and mostly focused on the big exposed services) does and everybody assumes others are.
Yeah, thats the brilliantly devious approach here. Malicious commit to source code in something like linux kernel would not succeed here.
attacker found critical yet understaffed software component (single unpaid maintainer - the author himself)
attacker wormed its way into position of small power, then full power over repository
attacker crafted build time testing scenario for to implement backdoor into compiled binary
note that xz source code is unchanged, as far as we know, only output binary has some extra pieces bolted on
microsoft software engineer notices ssh taking too much resources and investigates why
So social engineering campaign over few years and then side-channel attack.
If it were closed source project, we would not have ever known.
I would say this is early warning shot and also end of era of easy cooperative meritocracy. OSS projects of high value will not have to start verifying contributors in detail.
Installers, testing and packaging rarely gets the same love as the application code especially when under limited resources.
Some kind of automated dependency auditing is needed here. That’s the only thing I can think of offhand on how to stop something like this in the future.
Consider how many critical systems do run on open source software. At what point does it become the case that national security agencies should consider monitoring or providing protection to individuals involved in maintaining critical software like this? Draconian, sure. One can only imagine the number of ways this attack could have been made easier through the application of coercion or physical violence agains the principal developer. And it really does raise questions as to how common this is/has been.
Thanks for the heads-up, though!
Though NixOS sshd does not link against liblzma so it’s unlikely to have a practical effect for most people. Roll-back to 5.4.6 is in progress