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
