A Trusting-Trust Attack Against an Entire Linux Distro: Researchers Turn GNU strip Into a Weapon
A Trusting-Trust Attack Against an Entire Linux Distro: Researchers Turn GNU strip Into a Weapon
Open source security rests on a simple promise: review the source code and backdoors will be found. A new paper shows what that promise cannot cover, and demonstrates that an ordinary build utility can do what security folklore assumed only compilers could do.
A team from Télécom Paris and KTH Royal Institute of Technology in Stockholm (Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli, and Théo Zimmermann) published on arXiv the first documented end-to-end implementation of Ken Thompson’s “trusting trust” attack carried by GNU strip instead of a compiler, executed against a real NixOS build. The result: a complete graphical installer that builds without a single failure while nearly every executable inside it is backdoored.
What Happened
The paper, posted to arXiv as 2607.24888 on July 27, 2026, is both a theoretical and practical demonstration. The researchers did not find a vulnerability in NixOS or in GNU strip. They built a complete attack to prove that the scope of Thompson’s attack is wider than assumed. The payload is the string “You’ve been pwned!”, not real malware, and the full implementation is released as a replication package for inspection.
The Original Idea: Why Source Review Is Not Enough
In his 1984 Turing Award lecture “Reflections on Trusting Trust,” Ken Thompson showed that a compromised compiler can plant a backdoor in the programs it builds while also injecting the same self-reproducing logic into the next generation of the compiler itself. The source code stays perfectly clean, and any rebuild from that clean source produces trojanized binaries again.
For decades the attack remained a thought experiment discussed in security circles, alongside early warnings like the 1974 Karger and Schell Multics security evaluation, with no documented full implementation against a production distribution. The new paper closes that gap and reframes the problem: the weakness is not in compilers specifically, it is in any build tool that ships in a bootstrap seed and writes to build outputs.
Why GNU strip Specifically
GNU strip is a binutils utility that removes symbol tables and debug information from object files and executables after a build. It never reads or generates source code. But its position in the build pipeline gives it two properties that make it an ideal carrier:
- It touches everything. Every package in a distribution runs a fixup phase that invokes strip on its outputs, regardless of programming language. A compiler like gcc only compromises what it compiles; strip reaches every binary the distribution produces.
- It lives in the bootstrap seed. Building any distribution has to start from a small set of prebuilt binaries (about twenty tools in NixOS’s case: a C compiler, binutils, the C library, bash, coreutils, and more). This seed is accepted on trust, because you need working tools to build tools.
Whoever can replace one file in that seed owns the distribution. The paper states this threat model plainly: the attacker can modify one binary in the seed and cannot modify any build recipe or package source.
How the Attack Works: Three Stages
The first stage is seed tampering. The researchers injected the payload into strip’s executable using three ELF transformations that do not modify a single byte of the original program code: Append places the payload at the end of the file, Repurpose converts a spare PT_NOTE program header (which every modern binary carries as a build-id note) into an executable segment, and Redirect rewrites the entry point field in the ELF header so the processor jumps to the payload first. They also built a new section header table at the end of the file, containing a .payload section, so the binary stays coherent from the perspective of nixpkgs’s post-processing tools.
The second stage is propagation across strip generations. This is where Thompson’s mechanism actually plays out. When strip is rebuilt from clean source, the fixup phase runs the older (trojanized) strip over the newly built binaries, including the new strip itself. The compromised tool recognizes itself by process basename, implants the successor before stripping it, and the source stays clean. The cycle repeats through the bootstrap stages of nixpkgs until the payload reaches the strip of the final standard environment, after the original seed has already left the dependency closure.
The third stage is compromise. The payload is written as a freestanding program: no libraries, no libc, direct kernel calls, because the same bytes get implanted into executables with entirely different dependencies. When any backdoored binary runs, the payload executes first, checks the NIX_BUILD_TOP environment variable to stay silent inside Nix build sandboxes so nothing fails a functional test during a build, impersonates strip only when the process is actually named strip, then restores registers and jumps to the original entry point so the host program runs normally.
The Numbers
The researchers evaluated the attack on a real nixpkgs revision (fef9403a3e4d, using binutils 2.44 on x86_64-linux):
- The graphical ISO installer built with zero failures across roughly 2,000 packages.
- The final closure contained 1,199 package outputs and 3,799 user-invokable ELF executables, totaling 6.16 GB on disk.
- Of 3,791 directly invokable binaries, 3,790 printed the infection marker when run.
- The single clean binary was firefox 147.0.3, for a documented reason: its build recipe passes —disable-strip and —disable-install-strip, skipping the strip phase entirely. The exception proves the rule: the attack hits exactly what strip touches.
- Infection crossed language ecosystems: bash, git, sudo, curl, python3.13, and more. Programming language is irrelevant because the attack operates on binaries directly.
- The NixOS functional test suite for the graphical image passed completely, meaning the malicious behavior degrades nothing that tests can see during the build.
That last number is the most unsettling: the trojanized distribution passes all of its own functional tests. The build “succeeds,” the tests “pass,” and every binary is malicious.
Is NixOS More Vulnerable Than Others?
No. The trojanized seed scenario has nothing specific to NixOS; every distribution has the same structure under a different name. But NixOS (and GNU Guix) have something that genuinely reduces the attack’s practical value: reproducible builds and a culture of rebuilding nearly everything from source.
When every binary can be rebuilt from source and compared byte for byte, any unexplained difference between two independent builds is an alarm. Malka’s own earlier paper (published October 2025) explains how reproducible builds could have detected the 2024 xz attack. Deeper approaches like David Wheeler’s Diverse Double-Compiling, the Bootstrappable Builds project, and GNU Mes, which rebuilds the entire compiler chain from a minimal auditable source, attack the same root problem.
The practical difference: distributions that ship binaries straight from centralized build infrastructure are more exposed to the “one trojanized seed is enough” idea, and distributions that rebuild and verify detect this class of tampering. No distribution is fully immune, but independent verification shrinks the attack’s window.
What Developers Can Do
- Distribution and infrastructure builders: treat your bootstrap seed as a first-class attack surface. Any single binary in it is enough. Evaluate bootstrappable builds approaches and weigh their cost against the attack surface they remove.
- Security teams building from open source: do not treat signed binaries as sufficient. A signature proves the delivery chain, not the cleanliness of the original build. Enable Reproducible Builds where possible and verify independent rebuilds.
- NixOS or Guix users: use a trusted binary cache with signature verification enabled, and follow the reproducible-builds work in both projects. This paper is, if anything, another argument for the build-from-source discipline these systems are known for.
- Everyone else: remember that supply chain attack surface does not stop at the compiler. Any tool accepted on trust that writes into build outputs is a theoretical carrier.
Limitations
The paper is explicit about its boundaries. The threat model assumes an attacker who can modify the bootstrap seed itself, which is not a remote exploit; it requires access to the system producing the seed, an authorized update to a pinned seed, or social engineering of the seed review process. The payload in the prototype is a print statement, not functional malware. A rebuild from anything other than the trojanized seed is clean. And the attack as implemented targets x86_64-linux, binutils 2.44, and NixOS specifically; generalizing to other environments is plausible but not demonstrated.
One more point worth stating: a complete public implementation lowers the barrier for everyone. Even if this is not exploited in the wild today, the paper is required reading for anyone who builds software.