> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Tue, Apr 9, 2024, 10:57 Andreas Schwab <sch...@linux-m68k.org> wrote:
>
>> On Apr 09 2024, anderson.jonath...@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).
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
