Log date · Mon
Trusting trust without a compiler: a tampered strip backdoors a distribution bootstrap
Researchers made a tampered strip propagate through the NixOS bootstrap by manipulating ELF binaries alone, showing post-build tools belong to the trust chain.
What happened on 27 July
On 27 July 2026 at 12:59 UTC, v1 of Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation was submitted to arXiv. The authors challenge the view that Thompson's trusting-trust attack is specific to compilers by building a complete version around GNU strip, a utility that neither inspects nor generates source code; the attack works purely by manipulating finished ELF binaries. In the NixOS bootstrap, a single tampered strip in the binary seed passes its payload to the next generation of strip and persists into the final standard environment even after the seed leaves the dependency closure. On a real nixpkgs revision, the attack built a complete graphical installer and backdoored almost every one of its binaries.
Relevance to app hardening pipelines
The paper is closer to app protection than it first appears. Many hardening pipelines transform binaries after compilation: stripping symbols, rewriting sections, inserting checks, obfuscating and re-signing. Those tools sit in the same position as strip, unable to see source yet deciding what the final artifact contains. If any of them is replaced or tampered with, source review and code signing will not reveal it, because a signature proves an artifact came from your pipeline, not that it matches your source. Adding binary transformation tools therefore raises reverse-engineering cost while also widening what you must trust, and those tools deserve equally strict supply-chain controls.
Checks you can run
First, list every tool in your pipeline that modifies binaries after compilation, such as strip, post-link optimizers, obfuscators, packers and signing tools, record versions and sources, and verify hashes or signatures of downloaded tool packages. Second, make builds reproducible where possible: build the same commit in two independent environments, compare the unsigned artifacts and investigate any differences. Third, keep the pre-transformation version of hardened artifacts, and periodically compare exported symbols, section layout and behavioral test results between the two to confirm the transformation did only what was intended. Document the results so later audits can see what was checked.
Your checklist
- Inventory and verify every post-compile binary-modifying tool
- Reproduce builds in two independent environments and compare unsigned output
- Keep pre-transformation artifacts and compare structure and behavior
Primary sources
- arXiv: Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation (2607.24888) · Source date 2026-07-27 · Checked 2026-10-12