Ein manipuliertes strip kann ganz NixOS mit einer Hintertür versehen

Der Trusting-Trust-Angriff galt immer als Compiler-Problem. Eine Arbeit auf arXiv zeigt, dass er das nicht ist. Fünf Forscher bauten eine vollständige Fassung des Angriffs um GNU strip herum, ein Build-Werkzeug, das nie Quellcode liest oder schreibt. Damit versahen sie fast jede Binärdatei eines grafischen NixOS-Installers mit einer Hintertür.

Die Autoren sind Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli und Théo Zimmermann. Die Arbeit erschien am 27. Juli 2026.

Was der ursprüngliche Angriff war

Ken Thompson beschrieb die Idee 1984. Man manipuliert einen Compiler so, dass er in die Programme, die er baut, eine Hintertür einsetzt. Man bringt ihm außerdem bei zu erkennen, wann er sich selbst übersetzt, und dieselbe Manipulation in den neuen Compiler zu legen.

Danach kann der bösartige Quellcode gelöscht werden. Die Hintertür pflanzt sich über jeden Neubau fort, und der Blick in den Compiler-Quellcode verrät nichts.

Die Sicherheitsgemeinde behandelte das als compilerspezifische Bedrohung. Genau diese Annahme greift die Arbeit an.

Warum strip das Bild verändert

GNU strip entfernt Debug-Symbole aus übersetzten Dateien. Es sieht nie Quellcode. Es schreibt nur fertige ELF-Dateien um, das Standardformat für ausführbare Dateien unter Linux.

Die Forscher legten ein manipuliertes strip in den Binary Seed von NixOS, jene kleine Menge vorgebauter Binärdateien, mit der eine Distribution startet, bevor sie selbst etwas bauen kann. Von dort kopiert sich die Nutzlast in jede neue Generation von strip.

Sie übersteht dann den Weg in die endgültige Standardumgebung, nachdem der ursprüngliche Seed den Abhängigkeitsgraphen längst verlassen hat. Der manipulierte Startpunkt ist weg, die Hintertür bleibt.

Ausgeführt wurde das auf einer echten nixpkgs-Revision, fef9403a3e4d, mit GNU binutils 2.44 auf x86_64. Der Build lief ohne Fehler durch und lieferte einen funktionierenden grafischen Installer, in dem fast jede Binärdatei eine Hintertür trug.

Die Abwehrmaßnahmen, die das nicht fangen

Dieser Teil verdient genaues Lesen, denn die üblichen Antworten versagen auf jeweils eigene Weise.

Abwehr	Warum sie das verfehlt
Diverse Double-Compiling	Der Angriff "sits on both sides of the comparison and cancels out"
Reproduzierbare Builds	Ein Neubau mit demselben Seed reproduziert die Nutzlast Bit für Bit
Bootstrappable Builds	Hilft nur im Verhältnis dazu, wie klein der Binary Seed ist

Diverse Double-Compiling baut einen Compiler mit einem zweiten, unabhängigen Compiler neu und prüft, ob die Ergebnisse übereinstimmen. Die Autoren merken an, es "then checks that the two results agree", und genau diese Prüfung besteht eine Nutzlast, die in beiden Pfaden steckt.

Reproduzierbare Builds wollen "make every build produce bit-for-bit identical output", wobei ein unabhängiger Nachbauer bestätigt, dass eine Binärdatei zum Quellcode passt. Identische Ausgabe ist nicht dasselbe wie saubere Ausgabe.

Die Arbeit zeigt aber auf etwas, das hilft. "The full-source bootstrap in GNU Guix reduces the binary seed to a few hundred bytes and rebuilds the whole toolchain from auditable source above it", schreiben die Autoren. Ein kleinerer Seed heißt weniger nicht prüfbares Material, in dem sich etwas verstecken kann.

Was das für Entwickler bedeutet

Hören Sie auf, die vertrauenswürdige Basis mit dem Compiler gleichzusetzen. Jede Binärdatei in Ihrem Bootstrap, die andere Binärdateien umformt, gehört dazu, und das schließt strip, Linker, Archivierer und Installer ein. In den meisten Bedrohungsmodellen standen sie nie.

Wer sich für Sicherheit auf reproduzierbare Builds stützt, sollte genau verstehen, was sie belegen. Sie belegen, dass Ihr Build deterministisch ist. Sie belegen nicht, dass Ihre Eingaben sauber waren, und dieser Angriff ist bewusst deterministisch.

Wer NixOS produktiv betreibt, sollte einordnen, was passiert ist und was nicht. Der Angriff wurde von Forschern auf einer echten Revision vorgeführt, mit veröffentlichtem Replikationspaket. Eine öffentliche Reaktion des NixOS-Projekts gibt es nicht, und es gibt keinen Hinweis, dass jemand das außerhalb des Labors getan hätte.

Der praktische Hebel ist die Größe des Seeds. Die paar hundert Byte bei Guix sind eine andere Risikoordnung als ein üblicher Binary Seed. Fragen Sie nach dieser Zahl, wenn Ihnen jemand sagt, seine Distribution sei bootstrappable. Open-Source-Governance war dieses Jahr viel beschäftigt, von Debians Abstimmung über KI-gestützte Beiträge bis zur Auflösung des Nixpkgs-Kernteams. Dies erinnert daran, dass auch die Build-Pipeline Aufmerksamkeit braucht.