Re: Sourceware mitigating and preventing the next xz-backdoor

[Claudio Bantaloukas <Claudio.Bantaloukas@arm.com>]

On 09/04/2024 18:57, Andreas Schwab wrote:
> On Apr 09 2024, anderson.jonathonm@gmail.com wrote:
> 
>> - This xz backdoor injection unpacked attacker-controlled files and ran them during `configure`. Newer build systems implement a build abstraction (aka DSL) that acts similar to a sandbox and enforces rules (e.g. the only code run during `meson setup` is from `meson.build` files and CMake). Generally speaking the only way to disobey those rules is via an "escape" command (e.g. `run_command()`) of which there are few. This reduces the task of auditing the build scripts for sandbox-breaking malicious intent significantly, only the "escapes" need investigation and they which should(tm) be rare for well-behaved projects.
> 
> Just like you can put your backdoor in *.m4 files, you can put them in
> *.cmake files.
>

Hi Andreas,
Indeed you're right and seeing the hijacked CMakeLists.txt in the commit 
was eye opening.

There is a not so subtle difference though. The amount of nasty that the 
attacker thought could get away with was different between the 
build-to-host.m4 and the CMakeLists.txt attack vectors.

For the CMakeLists.txt file, the wanted change was very small, adding a 
dot to a piece of c code so that the test that runs it goes into one of 
the perfectly acceptable states (cannot compile the c file), thus 
disabling a security feature.
This change was "hidden" in a patch containing a bunch of pointless 
renames and veiled in plausible deniability (oops, that dot went in the 
by mistake, silly me, here's a patch to fix the file). The attacker was 
lucky because noone really checked.

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7;hp=eb8ad59e9bab32a8d655796afd39597ea6dcc64d

Compare that to what the m4 file did. Russ Cox has an interesting 
analysis https://research.swtch.com/xz-script

 From which I'll pick a choice quote: "makes a handful of inscrutable 
changes that don’t look terribly out of place".

I figured out the problem with the CMakeFile.txt quickly. I'm not 100% 
sure if the configure.ac is ok (after looking at it for 10 minutes, it 
looks ok, but I'm not sure!). I would not be able to recognise good code 
from bad in the m4 file.

Admittedly, I'm biased in favour of cmake's DSL, have more experience 
with it despite using ./configure since the mid 90s and have a 
preference. But it would be hard to argue against the fact that benign 
m4, as practiced in the wild today is hard to separate from malicious m4 
by a majority of developers, including experienced ones like Mr. Cox above.

Cheers,
Claudio Bantaloukas