Re: Sourceware mitigating and preventing the next xz-backdoor

[Jeffrey Walton <noloader@gmail.com>]

On Tue, Apr 9, 2024 at 4:11 PM Paul Koning via Gdb <gdb@sourceware.org> wrote:
>
> > 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 <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).
>
> 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.

In the Xz case, the victims should not have been able to execute a
well known but modified *.m4 file. The *.m4 files should have been on
the build machine already; or, the latest *.m4 files installed on the
build machine via an updated Autoconf; or the latest serial-numbered
*.m4 macro should have been fetched from a trusted source like GNU.
They provide the provenance needed to allow their execution.

In the browser world, content security policy (CSP) allows third party
code to execute, assuming a script-src and an integrity tag. The
provenance and integrity is enforced.

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

Code provenance and code integrity was not enforced. Part of the
problem is the Autotools design. It is from a bygone era. No one
should be able to override a named, GNU supplied m4 macro. That's a
bug, not a feature.

Jeff