15 ms·
"The exploit was caught promptly, so almost no users were affected. Debian sid, Fedora Rawhide, the Fedora 40 beta, openSUSE Tumbleweed, and Kali Linux all brie
by y_xc 3y ago
"The exploit was caught promptly, so almost no users were affected. Debian sid, Fedora Rawhide, the Fedora 40 beta, openSUSE Tumbleweed, and Kali Linux all briefly shipped the compromised package."
One thing that is noteworthy is that Kali Linux integrated the backdoor briefly.
So we should have a discussion about security of distros packaging speed. Is it more secure to integrate all patches as fast as possible or is it more secure to wait a bit until it is being tested elsewehere. The "elsewhere" would catch the bad effects then. Integrating security patches as fast as possible could be very costy.
- hypeatei 3y agoIt probably depends on what's being updated in the new version. If it's a vulnerability fix, then fast is good. If not, then waiting a little bit is ideal. Not sure how that would work in an automatic way without some sort of tagging system marking it as "critical" but that could be abused by bad actors too.
- greggsy 3y agoMost major distros include mechanisms to install packages not security updates, either via the package manager, or through specific repositories.
- ajross 3y ago> Is it more secure to integrate all patches as fast as possible or is it more secure to wait a bit until it is being tested elsewehere. That's a chicken/egg argument. Someone needs to be "elsewhere". Integration testing is absolutely part of security defense in depth architecture. In point of fact this was caught by running Debian testing. Delaying inclusion would have delayed discovery.
- y_xc 3y agoExactly that is my fear, too. It's like zero trust in everything. - Don't trust that any other party do the security testing for you - Don't trust any developer, it could have malicious intents - Don't trust the patches, they could introduce bugs/backdoors/... So we're straight going in the direction of protectionism and isolation. Wouldn't that be a big step back for the whole OSS/FOSS community? One thing I read the xc-writeups last days (I think it was here https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...) was that we at least shouldnt trust any devs/maintainers that have no online identity. Though the argument that you could create a fake ID is possible. So I'm still obsessed from the question, what are the lessons learned for the community from this and how restrictive the participation in OSS will become.
- ajross 3y agoI don't think that's quite right: Trust the community. Trust the process. Sure, any one actor might be compromised, but that will be rare and exceptional. So build layers such that their bad actions get detected and corrected. Some parts of that aparatus worked poorly in this case, it's true: xz had a single maintainer who turned out to be susceptible to a deliberate human engineering attack, and yet was trusted to be linked into the some of the highest-trust parts of the system. That's bad, and we should work to avoid that kind of situation in the future. But other bits worked very well: multiple downstreams detected the flaw (though only Andres saw it for the attack it really was), and it was corrected before it reached any production releases. The community as a whole is set up in the right way and doing the right things.
- jeltz 3y agoWasn't Debian testing also affected? That should have affected some people's PCs.