Rich, Duncan, Dale, orbea, you have to admit the situation with xz-utils is nothing like the typical scenario people usually worry about, where a bad actor manages to compromise a project and slip something into a widely used piece of software. No, this is the the bad actor *themselves* being a principal author of the software, working stealthily and in very sophisticated ways for years, to manoeuvrer themselves and their software into a position of trust in the ecosystem whereby they were almost able to pull off the mother of all security nightmares for the world. And many very smart people reviewed what they did and were fooled by them (which is no reflection on those people, it was just because the bad actor did a very, very good job of fooling them). I have to ask, if you still trust a codebase to be right at the heart of your system after that, what on earth would it take for you to start to feel uncomfortable??!!
Sometimes, it's good when you're inside the house that is on fire, to *not* stand there and say to yourself "well the engineers who built this place must have built it to withstand a fire, I'm sure it will stop burning soon. And anyway, the fire brigade will be here soon, I'm sure it will all be fine". I'm not saying the world of OSS & Linux is on fire, of course not. This is a very isolated and rare situation with just 1 piece of software. No, I'm just using probably a probably bad analogy to make the following point: while almost all of the time a reasoned, "lets just calm down and think about this" approach is right, in some rare situations it is important to see a situation as serious as it and act accordingly. In this case, if I weigh up the benefits of using this piece of software versus another (relatively small gains in file size reduction, some gains in resource usage) against the risks of continuing to use it (and lets be realistic about those risks please rather than "I'm sure it will all be fine"), the risks are far greater. Note, I'm not advocating ripping xz-utils out of tree, all I'm saying is wouldn't it be nice if there were at least 2 alternatives to choose from? That doesn't have to be disruptive in any way, people who wish to continue using and trusting xz-utils should be able to continue to do so without any friction whatsoever. Rich Freeman wrote: > On Sat, Mar 30, 2024 at 3:06 AM Dale <rdalek1...@gmail.com> wrote: > >> >> when I got to the part about it not likely to affect Gentoo, my level >> of concern dropped significantly. If this is still true, there's no >> need to be concerned. > > "not likely" is the best way to characterize this. The exploit has > not been fully analyzed, and it could have additional malicious behavior, > either designed by its author, or perhaps even unintended by its author. > > I just wanted to toss in that caveat, but agree that the defaults > deployed in Gentoo seem the most sensible for general use. There is > nothing magical about xz - ANY widely-used library could have something > like this embedded in it, and the attacker exploited what they had access > to in order to go after a configuration that was going to be widely > deployed and reachable (xz+deb/rpm+systemd+openssh). If the attacker had > an intended target that used gentoo+openrc and access to something in our > supply chain, this could have been a vulnerability that only impacted > Gentoo. > > > I think the big lesson here is that FOSS continues to suffer from core > dependencies that are challenged for resources, and that efforts to fix > this have to constantly keep up with the changing landscape. xz is going > on 15 years old, but I don't think it was nearly as commonly used until > fairly recently. > > libz has been a pretty well-known source of security flaws for ages > (granted, usually not intentional like this). It isn't too surprising > that in both cases compression libraries were targeted, as these are so > widely depended on. > > This is getting tangential, but part of me wonders if there is a > better way to do authentication. Programs like ssh tend to run as root so > that they can authenticate users and then fork and suid to the appropriate > user. Could some OS-level facility be created to allow unprivileged > processes to run the daemons and then as part of the authentication > process they can have the OS accept a controlled and minimal set of data > to create the process as the new user and hand over the connection? PAM > already has a large amount of control over the authentication process, so > it seems like we just need to change the security context that this runs > in. That's just brainstorming-level thinking though - there could be > obvious issues with this that just haven't occurred to me. > > -- > Rich > > > >
