Re: Sourceware mitigating and preventing the next xz-backdoor

[Jonathon Anderson <anderson.jonathonm@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On Tue, Apr 9, 2024, 10:57 Andreas Schwab <schwab@linux-m68k.org> 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.


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).

If your build system is Meson, you can easily consider CMake code to be an
escape and give it a little more auditing attention. Or just avoid shipping
CMake scripts entirely, they are are rarely necessary.

-Jonathon

>