Re: Sourceware mitigating and preventing the next xz-backdoor
Hello all, On Wed, 2024-04-03 at 16:00 +0200, Michael Matz wrote: > > My take a way is that software needs to become less complex. Do > > we really still need complex build systems such as autoconf? > > (And, FWIW, testing for features isn't "complex". And have you looked at > other build systems? I have, and none of them are less complex, just > opaque in different ways from make+autotools). Some brief opinions from a humble end-user: I think the key difference here is that Autotools allows arbitrarily generated code to be executed at any time. More modern build systems require the use of specific commands/files to run arbitrary code, e.g. CMake (IIRC [`execute_process()`][2] and [`ExternalProject`][3]), Meson ([`run_command()`][1]), Cargo ([`build.rs`][4]).\ IMHO there are similarities here to the memory "safety" of Rust: Rust code can have memory errors, but it can only come from Rust code declared as `unsafe` (or bugs in the compiler itself). The scope is limited and those scopes can be audited with more powerful microscopes... and removed if/when the build system gains first-class support upstream. There are other features in the newest build systems listed here (Meson and Cargo) that make this particular attack vector harder. These build systems don't have release tarballs with auxiliary files (e.g. [Meson's is very close to `git archive`][5]), nor do their DSLs allow writing files to the source tree. One could imagine a build/CI worker where the source tree is a read-only bind-mount of a `git archive` extract, that might help defend against attacks of this specific design. It's also worth noting that Meson and Cargo use non-Turing-complete declarative DSLs for their build configuration. This implies there is an upper bound on the [cyclomatic complexity][6]-per-line of the build script DSL itself. That doesn't mean you can't write complex Meson code (I have), but it ends up being suspiciously long and thus clear something complex and out of the ordinary is being done. Of course, this doesn't make the build system any less complex, but projects using newer build systems seem easier to secure and audit than those using overly flexible build systems like Autotools and maybe even CMake. IMHO using a late-model build system is a relatively low technical hurdle to overcome for the benefits noted above, switching should be considered and in a positive light. (For context: my team recently switched our main C/C++ project from Autotools to Meson. The one-time refactor itself was an effort, but after that we got back up to speed quickly and we haven't looked back. Other projects may have an easier time using an unofficial port in the [Meson WrapDB][7] as a starting point.) -Jonathon [1]: https://mesonbuild.com/External-commands.html [2]: https://cmake.org/cmake/help/latest/command/execute_process.html#execute-process [3]: https://cmake.org/cmake/help/latest/module/ExternalProject.html [4]: https://doc.rust-lang.org/cargo/reference/build-scripts.html [5]: https://mesonbuild.com/Creating-releases.html [6]: https://en.wikipedia.org/wiki/Cyclomatic_complexity [7]: https://mesonbuild.com/Wrapdb-projects.html
Re: Sourceware mitigating and preventing the next xz-backdoor
On Tue, Apr 9, 2024, 10:57 Andreas Schwab 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). 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 >
Re: Sourceware mitigating and preventing the next xz-backdoor
On Tue, 2024-04-09 at 16:11 -0400, Paul Koning wrote: > > On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc > <[gcc@gcc.gnu.org](mailto:gcc@gcc.gnu.org)> wrote: > > > 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. In Autotools, `make dist` produces a tarball that contains many files not present in the source respoitory, it includes build system core files and this fact was used for the xz attack. In contrast, for newer build systems the "release tarball" is purely a snapshot of the source repository: there is no `cmake dist`, and `meson dist` is essentially `git archive` ([docs](https://mesonbuild.com/Creating-releases.html)). Thus for the injection code to be present in the release tarball, it needs to have first been checked into the repository. In fact, packagers don't *need* to use the tarballs, they can (and should) use the Git history from the source repository itself. In Debian this is one workflow implemented by the popular git-buildpackage ([docs](https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html)). The third-party package manager [Spack](https://spack.readthedocs.io/en/latest/packaging_guide.html#git) clones directly from the source repository. Others may have support for this as well, this isn't a novel idea. -Jonathon
Re: Sourceware mitigating and preventing the next xz-backdoor
On Tue, 2024-04-09 at 14:50 -0700, Paul Eggert wrote: > On 4/9/24 14:40, Jeffrey Walton wrote: > > > Code provenance and code integrity was not enforced. Part of the > > problem is the Autotools design. It is from a bygone era. > > > No, Andreas is right. This isn't an Autotools-vs-Meson thing. > > Most of the Autotools-based projects I help maintain would have been > immune to this particular exploit, partly because they don't maintain > their own of Gnulib .m4 files. Conversely, any Meson-based project that > had the same sort of out-of-repository sloppiness and lack of review > that xz had, would be vulnerable to similar attacks. Xz doesn't either, the exploit was unique to the distributed `make dist` tarballs. Which is an Autotools quirk present in all Autotools projects. I won't deny that a project could use Meson and be sloppy, a project could use SSL/TLS/whatever and be completely insecure. But Autotools encourages and semi-requires this sloppy behavior, and CMake and Meson strongly discourage this behavior. -Jonathon
