New trusting-trust attack backdoors NixOS via GNU strip

Researchers from Télécom Paris and KTH just proved you don't need a backdoored compiler to compromise an entire Linux distribution. A tampered strip — the utility that strips debug symbols from binaries — is enough.

Trusting trust was never just a compiler problem

In his 1984 Turing Award lecture, Ken Thompson described the classic thought experiment: a compromised compiler can plant a backdoor in every program it builds, and reproduce that backdoor every time it recompiles itself — even from clean source. For four decades, security researchers treated this as a compiler-specific problem, since only a compiler actually parses and "understands" source code well enough to recognize and modify itself.

A new arXiv paper (authors Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli, and Théo Zimmermann) breaks that assumption. They built a complete trusting-trust attack around GNU strip — a tool that never reads or generates source code, only manipulates finished ELF binaries. No parsing, no language awareness, and it still works as a self-propagating backdoor carrier.

How the backdoor survives generation after generation

The attack targets NixOS's bootstrap process — the sequence that builds an entire package ecosystem from an initial set of binary "seeds," then layers everything else on top. The researchers planted a tampered strip binary directly into that seed. From there, the payload propagates through each successive generation of strip rebuilt from source — clean source, no less — and survives even after the original seed binary drops out of the dependency closure.

The most unsettling part: on a real nixpkgs revision, the attack built a complete graphical installer with zero build failures, backdooring almost every binary inside it. No failed checksums, no build errors that standard tooling would flag — because the build process itself follows normal logic the whole way through. Only the post-build tool is lying.

Why NixOS, and why this isn't a NixOS-specific flaw

NixOS wasn't picked because it's weaker than other distros — quite the opposite. It's one of the systems most focused on reproducible builds, where rebuilding from identical source should, in theory, produce identical output and expose tampering. That transparency in the bootstrap chain is exactly what made it a clean environment to demonstrate the proof of concept. Which also means the opposite is likely true elsewhere: distros with murkier bootstrap chains — Debian, Arch, or any system that bootstraps from a binary seed — probably share the same underlying weakness. Nobody has just proven it publicly yet.

What this means for developers

• Reproducible builds aren't a cure-all. They catch divergence between two builds of the same source, but if the original seed is already compromised, two "identical" builds both carry the same backdoor.
• Any post-build tool is an attack surface — not just compilers. Strippers, linkers, packers, anything that touches the final artifact deserves the same scrutiny.
• Binary seed provenance needs the same rigor as source code review. Any team bootstrapping a toolchain from precompiled binaries — a seed archive, a downloaded Docker base image, a prebuilt toolchain — should be asking how far back that binary's provenance was actually audited.
• Diverse double-compiling (cross-building with independent compilers and comparing output) remains the best known defense against trusting-trust attacks, but this paper widens the scope of what needs it — not just compilers, the whole post-build toolchain.

Four decades after Thompson's lecture, the question of who to trust in the build chain still doesn't have a clean answer. It just got one layer wider.

---

Content assisted by AI (Amy 🌸). Reviewed by the author.