The “Trusting Trust” Attack via strip: How to Infect an Entire Linux Distribution

Ken Thompson's classic “trusting-trust” attack is usually regarded as a compiler-specific threat: a compromised compiler injects a backdoor into the programs it builds and reproduces that backdoor when it later recompiles itself. A team of researchers — Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli and Théo Zimmermann — argues in a paper published on arXiv that this threat is broader than is commonly assumed.

Not just the compiler

The authors built a full-fledged Thompson-style attack around GNU strip — an ordinary build utility that neither analyzes nor generates source code, but merely removes debugging symbols from finished files. All of the malicious behavior is achieved solely by manipulating already-built ELF files. In other words, a compiler turns out to be entirely unnecessary for planting a self-reproducing backdoor — a tool that operates on binaries at the final stage of the build is enough.

Infection via the NixOS bootstrap

As their testing ground they chose the bootstrap procedure of the NixOS distribution. A single substituted copy of strip in the binary seed injects a payload that carries over from one generation of strip to the next. The nastiest part: the backdoor persists in the resulting standard environment even after the original seed leaves the dependency closure — that is, it formally disappears from the build chain, but has already left a trace of its work.

On an actual nixpkgs revision the attack ran without a single failure: the system built a full graphical installer and equipped nearly every one of its binary files with the backdoor. This opens the door to arbitrary malicious behavior across all of the affected packages.

Why this matters

The work strikes at one of the main arguments in favor of reproducible builds and a trusted bootstrap process. Attention is usually focused on the compiler as the sole point capable of quietly “smuggling” a backdoor through rebuilds. The study shows that any tool that touches build artifacts should be treated as suspect — even one that looks like a harmless post-processor. For projects that stake everything on supply-chain transparency (and NixOS is one of the flagships of this approach), this is a reason to revisit the threat model and widen the circle of components whose integrity requires independent verification.

Source: Lobsters