A backdoor in xz

Posted Mar 29, 2024 19:10 UTC (Fri) by zwenna (guest, #64777)
In reply to: A backdoor in xz by bluca
Parent article: A backdoor in xz

> We were pretty much on the brink of disaster, and got saved because someone's login got slowed down enough that they went "mmh hang on a sec".

I do not think that we actually got saved, at least saying so is premature until the payload has been analyzed in more detail. Right now I assume most Debian developers' machines are compromised.

This might very well be a much worse disaster than the 2008 Debian OpenSSL debacle, but time will tell.

A backdoor in xz

Posted Mar 29, 2024 19:28 UTC (Fri) by bluca (subscriber, #118303) [Link] (1 responses)

This was caught before it got in any stable release of any distribution, it's only in development/testing. The only exception is SUSE Tumbleweed, because it's rolling.

Just a few weeks of delay and it would have been part of the new Fedora 40 release and the new Ubuntu LTS 24.04 release.

A backdoor in xz

Posted Mar 30, 2024 19:47 UTC (Sat) by tao (subscriber, #17563) [Link]

I'd wager that most Debian developers use development/testing for their development systems. So "only" getting into development/testing is still quite bad.

A backdoor in xz

Posted Mar 29, 2024 19:34 UTC (Fri) by branden (guest, #7029) [Link] (1 responses)

> This might very well be a much worse disaster than the 2008 Debian OpenSSL debacle, but time will tell.

I wonder if we'll see an encore performance from sneering OpenSSL developer Ben Laurie, derogating the diligence and competence of "vendors" (distributors) once again.

https://web.archive.org/web/20090425084641/https://www.li...

Think how much better the xz episode could be turning out if we'd simply trusted upstream--the real experts.

A backdoor in xz

Posted Mar 30, 2024 14:16 UTC (Sat) by epa (subscriber, #39769) [Link]

You can still turn it into a “vendors suck” narrative since the dependency on xz is not there in OpenSSH, nor in the Portable version, but was patched in by Linux distributions.

Of course there is a reason for that — the upstreams don’t want systemd integration as it doesn’t fit their vision for the project. In some friendlier alternative universe upstream could have said “okay we can add the feature, but linking in the whole libsystemd is too much extra stuff to audit: any chance you can provide a slimmer library?”

A backdoor in xz

Posted Mar 29, 2024 20:50 UTC (Fri) by simon.d (guest, #168021) [Link]

This is exactly why I use a dm-verity to verify my rootfs (built with verity-squash-root). I can get compromised temporarily while online, but I only rebuilt and sign my image while offline on a fresh reboot. Ok, it would have saved me here, but probably not on a different compromise of a package, when already built into my system. Also secrets decrypted while compromised would also be compromised, but at least I can revert back to a secure system.

A backdoor in xz

Posted Mar 30, 2024 1:07 UTC (Sat) by DimeCadmium (subscriber, #157243) [Link]

I doubt "most Debian developers' machines" have publicly accessible SSH. Given that outbound/unprompted network traffic would be easily detectable, I think the assumption going around that you need to be able to access the system remotely to trigger the backdoor is correct.