Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

["Eddie Chapman" <eddie@ehuk.net>]

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 <rdalek1967@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
>
>
>
>