Re: Sourceware mitigating and preventing the next xz-backdoor

> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc <[email protected]> wrote:
> 
> On Tue, Apr 9, 2024, 10:57 Andreas Schwab <[email protected]> wrote:
> 
>> On Apr 09 2024, [email protected] 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.
> 
> 
> CMake has its own sandbox and rules and escapes (granted, much more of
> them). But regardless, the injection code would be committed to the
> repository (point 2) and would not hold up to a source directory mounted
> read-only (point 3).

Why would the injection code necessarily be committed to the repository?  It wasn't in the xz attack -- one hole in the procedures is that the kits didn't match the repository and no checks caught this.  I don't see how a different build system would cure that issue.  Instead, there needs to be some sort of audit that verifies there aren't rogue or modified elements in the kit.

	paul