On 09/04/2024 18: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. >
Hi Andreas, Indeed you're right and seeing the hijacked CMakeLists.txt in the commit was eye opening. There is a not so subtle difference though. The amount of nasty that the attacker thought could get away with was different between the build-to-host.m4 and the CMakeLists.txt attack vectors. For the CMakeLists.txt file, the wanted change was very small, adding a dot to a piece of c code so that the test that runs it goes into one of the perfectly acceptable states (cannot compile the c file), thus disabling a security feature. This change was "hidden" in a patch containing a bunch of pointless renames and veiled in plausible deniability (oops, that dot went in the by mistake, silly me, here's a patch to fix the file). The attacker was lucky because noone really checked. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7;hp=eb8ad59e9bab32a8d655796afd39597ea6dcc64d Compare that to what the m4 file did. Russ Cox has an interesting analysis https://research.swtch.com/xz-script From which I'll pick a choice quote: "makes a handful of inscrutable changes that don’t look terribly out of place". I figured out the problem with the CMakeFile.txt quickly. I'm not 100% sure if the configure.ac is ok (after looking at it for 10 minutes, it looks ok, but I'm not sure!). I would not be able to recognise good code from bad in the m4 file. Admittedly, I'm biased in favour of cmake's DSL, have more experience with it despite using ./configure since the mid 90s and have a preference. But it would be hard to argue against the fact that benign m4, as practiced in the wild today is hard to separate from malicious m4 by a majority of developers, including experienced ones like Mr. Cox above. Cheers, Claudio Bantaloukas
