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