Re: xz meltdown/Lasse Collin

On Sat, Apr 13, 2024 at 10:12:44AM -0400, James Bottomley wrote:
> 
> I gave an idea for that above.  But the first key step is pro-active
> identification.  The MO of the burnout attack was to try to make the
> attacker the single help resource; people in this position tend not to
> know they need to ask for other help.  So the first step has to be pro-
> active in looking for them (which is also useful for providing a risk
> report about the entire ecosystem).

It's important not to over-index on the specifics of how the xz-utils
attack was carried out.  Yes, this time the attack was carried out by
trying to identify someone who was close to being burned out.  It also
involved generated files and autotools.  But that's not the only way
such an attack could be carried out.

If we're talking about a nation-state with a vast amount of resources
and patience, the next time the attack might involve someone just
becoming a trusted contributor and contributing years of good work and
reviews before trying to submit a change which introduces some other
kind of back door or bug.

Perhaps the next attack will involve getting an agent hired by a major
AI chip vendor, and the backdoor will be hidden inside the proprietary
binaries distributed by that AI chip vendor to download firmware into
that company's GPU.  (And if these propietary drivers and binaries are
used by a large number of hyperscale cloud vendors, a backdoor into
that GPU driver or the GPU's support binaries would
be.... devastating.)

That's not to say that we shouldn't find ways to better support
https://xkcd.com/2347.  Or that we interrogate whether autotools is
the best long-term solution, or how to come up with a better solution
without going down the systemd approach of "we only care about Linux
and all other OS's are Not Our PRoblem).  Or that we should have tools
that look for differences between binaries built for distributions
versus built out of the git tree, perhaps by looking for behavioral or
performacne differences.

But let's not over-focus on the burnout attack, or the "only activate
if the build infrastructure is Debian or Fedora" attributes of what
happened this time around.  It is very likely that the next attempt to
subvert software supply chain will be quite different.

		 	      	      - Ted