How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
I'm glad they mention Wheeler's work briefly in section 7.2, since it provides a general counter to the trusting-trust attack that a lot of people seem to not know about. They dismiss it as not applying in this case, but I'm not really convinced by their argument. It's true if you only replace the compiler and run in the same environment then it won't help, but IIRC Wheeler's approach treats the environment itself as a parameter to diversify on. So not just the compiler, but also the host/OS, and even the hardware. Thus it's trivial to extend it to strip. Build binutils from source with your bad distro toolchain, fixup with your distro strip, call this build A. Then build binutils from source in a diverse environment, which includes fixup with a diverse stripper, call this B. Then do a rebuild (same diverse environment) but with B's toolchain and stripper, call this C, and compare C with A. Mismatch busts the attack.
FYI, x86_64-linux and i686-linux nixpkgs bootstrap seed is not 25 bundled binaries, but 181 bytes, since https://github.com/NixOS/nixpkgs/pull/479322. at publication date this article would apply to non-x86 platforms like aarch64-linux, risvc64-linux, etc.
if you're concerned about this and not on x86, i encourage you to extend this to other platforms! i believe it's possible to generalize this to every linux platform musl itself supports, in time.
FYI, I reviewed the live-bootstrap project that starts with a small seed. For a T-diagram that shows all processes being executed in stage0, have a look at [1].
I did work on a solution that requires less steps, but starts with a bit larger seed (though maybe documented a bit better), see [2] and [3] for the T-diagram. Also has targets for x86_64 and arm64. (Work on RISC-V has started.)
The solution to this in the Orange Book (TCSEC) days in the 1980's-1990's was a system fully traceable from requirements to code, proven to embed a security policy, and analyzable and buildable from source locally by the customer using existing, trusted tools. Eventually, people added hashes for the code and data.
So, your program that combines source files or checks dependencies would be fully specified in its success and failure states. Only combinations of functions leading to a provably-secure state are even allowed. If you can't do that, the feature is too complex to allow. Human pentesters review it from design to algorithms to building it to spot ways attacks might happen.
That's what it takes to build software that usually resists subversion. Most software isn't built that way. It can't be because the priorities of developers and customers work against it. So, we'll continue to see clever attacks that exploit systems not designed to high security standards.
For this topic, I recommend David A. Wheeler's page on Software, Configuration Management Security because it covers many issues with it in mostly-centralized systems.
> Most software isn't built that way. It can't be because the priorities of developers and customers work against it.
The most significant such priority may be the costs of paying developers and of time to delivery.
The dramatic reductions in those costs due to LLMs enable us to produce much more quantity and/or quality. Many complain now about quantity, so perhaps we are finally at a stage where we don't need much more software, and can focus on quality. Also, LLM attackers create demand for higher quality.
In other words, LLMs might enable us to some of these things that were impossible before.
Ran into this doing reproducible builds at a previous job. Reproducible builds don't fix trusting-trust by themselves, but they make it detectable: if you can rebuild the compiler bit-for-bit from a different toolchain and diff the output, a backdoored binary sticks out. Debian's rebuilder infra caught stuff this way.
If you have malware on your CI machine it can infect the artifacts it creates.
In this paper the malware was a strip trojan, but it could have been just as well a normal piece of malware which starts a service and then waits for the final artifact to be generated after which it infects it.
Rebuilding strip from clean source doesn't clear it. The copy in the bootstrap seed modifies its replacement, and the replacement carries on from there. The provenance can still look normal.
Generally speaking, Linux doesn't suffer from ELF-executable-file-infecting viruses in practice, because most random executables aren't run with root permissions, so they don't have permission to write to widely-executed executables, which you install from the package system.
However, anything in the build toolchain that someone uses to build those widely-executed executables necessarily does have permission to write to them!
This is certainly not novel, having been the subject of a Turing Award speech, but it is something that many people haven't thought through.
Nitpick: it's not really root vs non-root, it's write access to the file. npm -g, cargo install, homebrew all happily let a regular user overwrite executables in $PATH. Root's just the common case on shared boxes. Still, the toolchain trust point stands either way.
> Ken Thompson's trusting-trust attack [...] is widely regarded as a threat specific to compilers. We show that it is not
And yet, from Reflections On Trusting Trust:
> In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode.
The paper is certainly a nice worked-out example of the attack, which is worthwhile, but it's not novel.
It goes back to Paul Karger's MULTICS Security Evaluation where he invented and described the attack. Thompson learned it from him. Karger invented a lot of attacks and security techniques a decade or more ahead of the hacking community.
27 years ago we named this link virus. It worked well on DOS, Windows and on every other OS where the user who executed a infected file had enough access rights to change other executables.
But this one is crippled because there is only one file that can infect other files.
Read paper compiler bootstrap angle, not ML. Same trick Thompson demoed in '84 — compiler recognizes login.c source, injects backdoor, then recognizes own source during self-compile to keep injecting without leaving traces. Neat part here is they actually pulled it off across whole distro toolchain, not just proof of concept.
The Nix project has been able to bootstrap an entire Linux distribution from scratch. However, doing that traditionally relies on binary seeds -- meaning the very first compiler in the chain is downloaded as a prebuilt binary rather than compiled from a fully verified source. This leaves a single foundational gap where users will have to trust trust an external black-box binary. Efforts toward reproducible builds and reducing this trust perimeter focus on removing binary seeds and tracing every compilation step back to a minimal, manually verifiable root.
Ken Thompson's Trusting Trust is an interesting conundrum... there are ways to minimize the need to trust however, if you can express everything in the same language or common runtime:
Everyone's pointing at Guix/Nix full-source-bootstrap like it solves this, but it just moves the trust boundary down to the seed interpreter and the CPU running it. You still have to trust something you didn't compile yourself. Diverse double-compiling actually addresses the attack; a smaller seed doesn't.
