How the XZ backdoor works

Posted Apr 2, 2024 23:56 UTC (Tue) by Heretic_Blacksheep (guest, #169992)
In reply to: How the XZ backdoor works by randomguy3
Parent article: How the XZ backdoor works

Also in its current form, it isn't a valid threat/attack on MacOS, *BSD, etc. Just specific Linux environments... though arguably it's targeted at the two most popular server OSes (Debian & RedHat). Anyone that uses a Mac or Windows system as their development front end wasn't going to be directly compromised on their client system by this particular operation - not that we know the full scope of "Jian Tan's" efforts yet, if ever. There's likely other fully compromised projects out there that haven't been caught. Scary thought. I do hope distros take note about auditing what goes into their repositories... and in particular OpenBSD because the base system isn't very useful to most people without the contributed 3rd party package repository. After all, this one was only accidentally discovered by someone fanatical about performance metrics. No one outside the project was bothering to fully audit the source code. In some cases, Jian Tan successfully got security barriers lowered in other projects as well, likely testing oversight and competence as well as preparing for further compromise. No one was critically viewing those commits despite the diffs being obviously security adverse!

I'm glad to see the follow up article because a lot of early reporting from various outlets are working from incomplete information and therefore drawing incorrect conclusions ie: not just an authentication bypass, it's an arbitrary RCE injection which makes it far worse had it made to widespread distribution in RHEL 10(?) or Debian 13.

For OpenSSH's role in the chain, there's a feature request submitted to change its behavior for security certificates along with a diff already offered for review. https://bugzilla.mindrot.org/show_bug.cgi?id=3675

For Lasse Collin this has to be a nightmare scenario for him and I am sympathetic to his problems. I do wonder if he will assign the xz project and copyright to a well known open source foundation in the future who may be better suited to monitor and audit contributions if he hasn't the time and a lack of people he believes he can trust.

(?) Not sure how RHEL does its updates with regards to specific packages as I don't use it, 10 is the next major version anyway.

How the XZ backdoor works

Posted Apr 3, 2024 8:20 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

RHEL does rebase some packages to a newer upstream version, but that's rare for packages that don't have a substantial upstream community behind them. xz would have been updated to 5.6.1 in RHEL 10 (because it's forked from Fedora 40 which had it) but not before.

How the XZ backdoor works

Posted Apr 3, 2024 15:31 UTC (Wed) by mario-campos (subscriber, #152845) [Link]

>I do hope distros take note about auditing what goes into their repositories... and in particular OpenBSD because the base system isn't very useful to most people without the contributed 3rd party package repository.

While I do agree that this speaks to a larger problem for all distros, I disagree that OpenBSD is somehow more susceptible. OpenBSD is, by design, more minimal, which means that if a backdoor exists in a 3rd-party package, one must choose to install it -- secure by default. Whereas, on other distros, such packages might already be included by default -- insecure by default.

How the XZ backdoor works

Posted Apr 3, 2024 16:53 UTC (Wed) by emaste (guest, #121005) [Link]

This specific type of threat is also mitigated on FreeBSD as we include xz in the base system but replace the upstream build infrastructure with our own. We did import 5.6.0, but stripped out the compromised autoconf output and the payload in the test cases. (Other BSDs also replace the build tooling in their base systems.)