Re: Switching away from XZ

[Jonathan Schleifer <js%NetBSD.org@localhost>]

Am 01.04.24 um 22:30 schrieb Alistair Crooks:

> I cannot see how this would benefit anyone - in general, if your intent 
> is to ensure that the xz library/binary is not installed on a given 
> system, then that couldn't be achieved while any distfile is compressed 
> with the xz algorithm. And, since pkgsrc has no control over how 3rd 
> party software is compressed, and xz is still the most efficient 
> algorithm, I'd see that as not being achievable.

I think you're misunderstanding me here quite a bit.

The idea is that it is quite likely that the reason behind sabotaging 
sandboxes is that the attacker wants to create malicious .xz files as 
they are sitting on a 0day. That means the fewer .xz files you extract, 
the better. We don't know which other projects the attacker controls, 
and they could just release a .tar.xz for some project that exploits xz 
itself to get code execution.

> I also think your analysis is flawed - see Filipe Valsorda's analysis of 
> the issue - it's not an auth bypass, but a sophisticated RCE. See also 
> Kevin Beaumont's analysis, which surmises that the execution of the 
> backdoor was accelerated by the move to make more of systemd 
> dependencies into modules, to slim it down, and to reduce the attack 
> surface.

You are mixing up two things here that have absolutely nothing to do 
with each other.

1.) The one is the backdoor that has been found.
2.) The other is that the same author also did several other commits to 
weaken security in xz, including disabling sandboxes.

If an attacker only wants to do 1.), then 2.) will just raise more 
suspicion, so an attacker would only do it if there is a reason to.

So what could such a reason be? That while working on XZ, they found a 
buffer overflow or similar that also allows them to execute code when a 
.tar.xz file is extracted - except that the sandbox got in the way, 
which basically only allows to read() on the input file and write() the 
output file.

> Preventing an xz library or binary appearing on a Linux box 
> with pkgsrc wouldn't help this, using a patched or backdoor-predating xz 
> binary would be vastly superior, and not involve any distfile churn. If 
> your SBOM on linux can't distinguish between backdoored and 
> non-backdoored, you've got bigger problems

This is not about having xz installed on the system or not, this is 
decreasing the impact of the possibility that the attacker also controls 
another open source project and sits on a 0day that they can use.

> And then there's the data storage/transfer cost of not using the most 
> efficient compression algorithm

It's negligible in most cases.

> And finally, the poor developer(s) who ends up maintaining xz going 
> forward will now come under excruciating scrutiny, accompanied by 
> aggressive audits of everything that is done. As will other compression 
> methods, and systemd subsystems. Hopefully, systemd itself, too :)

A lot of software gets a lot of scrutiny and still 0days are found after 
decades.

--
Jonathan