Un binaire strip trafiqué peut piéger tout NixOS

L'attaque trusting-trust a toujours été décrite comme un problème de compilateur. Un article sur arXiv montre que ce n'en est pas un. Cinq chercheurs ont construit une version complète de l'attaque autour de GNU strip, un outil de compilation qui ne lit ni n'écrit jamais de code source. Ils s'en sont servis pour piéger presque tous les binaires d'un installateur graphique NixOS.

Les auteurs sont Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli et Théo Zimmermann. L'article a été mis en ligne le 27 juillet 2026.

Ce qu'était l'attaque d'origine

Ken Thompson a décrit l'idée en 1984. On trafique un compilateur pour qu'il insère une porte dérobée dans les programmes qu'il produit. On lui apprend aussi à reconnaître le moment où il se compile lui-même, et à replacer la même altération dans le nouveau compilateur.

Ensuite, le code source malveillant peut être supprimé. La porte dérobée se reproduit à chaque reconstruction, et lire le source du compilateur n'apprend rien.

La communauté de la sécurité a traité cela comme une menace propre aux compilateurs. C'est précisément cette hypothèse que l'article attaque.

Pourquoi strip change le tableau

GNU strip retire les symboles de débogage des fichiers compilés. Il ne voit jamais de code source. Il ne fait que réécrire des fichiers ELF finis, le format exécutable standard sous Linux.

Les chercheurs ont placé un strip trafiqué dans la graine binaire de NixOS, ce petit ensemble de binaires précompilés à partir duquel une distribution démarre avant de pouvoir construire quoi que ce soit. De là, la charge se recopie dans chaque nouvelle génération de strip.

Elle survit ensuite jusque dans l'environnement standard final, une fois la graine d'origine sortie du graphe de dépendances. Le point de départ trafiqué a disparu, la porte dérobée demeure.

Ils l'ont exécutée sur une vraie révision de nixpkgs, fef9403a3e4d, avec GNU binutils 2.44 sur x86_64. La compilation s'est déroulée sans échec et a produit un installateur graphique fonctionnel dont presque tous les binaires étaient piégés.

Les défenses qui ne l'attrapent pas

Cette partie mérite une lecture attentive, car les réponses habituelles échouent chacune à sa manière.

Défense	Pourquoi elle passe à côté
Diverse double-compiling	L'attaque "sits on both sides of the comparison and cancels out"
Compilations reproductibles	Reconstruire avec la même graine reproduit la charge bit pour bit
Compilations amorçables	N'aide qu'en proportion de la petitesse de la graine binaire

Le diverse double-compiling reconstruit un compilateur avec un second compilateur indépendant et vérifie que les résultats concordent. Les auteurs notent qu'il "then checks that the two results agree", et c'est exactement le contrôle que passe une charge présente dans les deux chemins.

Les compilations reproductibles visent à "make every build produce bit-for-bit identical output", un reconstructeur indépendant confirmant qu'un binaire correspond à son source. Une sortie identique n'est pas une sortie propre.

L'article désigne tout de même une piste utile. "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", écrivent les auteurs. Une graine plus petite, c'est moins de matière non auditable où se cacher.

Ce que cela signifie pour les développeurs

Cessez d'assimiler la base de confiance au compilateur. Tout binaire de votre amorçage qui transforme d'autres binaires est concerné, ce qui inclut strip, les éditeurs de liens, les archiveurs et les installateurs. La plupart des modèles de menace ne les ont jamais listés.

Si vous vous appuyez sur les compilations reproductibles pour vos garanties, comprenez exactement ce qu'elles prouvent. Elles prouvent que votre compilation est déterministe. Elles ne prouvent pas que vos entrées étaient saines, et cette attaque est délibérément déterministe.

Si vous exploitez NixOS en production, distinguez ce qui s'est produit de ce qui ne s'est pas produit. L'attaque a été démontrée sur une révision réelle par des chercheurs, avec un paquet de réplication publié. Il n'y a pas de réponse publique du projet NixOS, et rien n'indique que quiconque ait fait cela hors du laboratoire.

Le levier pratique est la taille de la graine. Les quelques centaines d'octets de Guix relèvent d'un autre ordre de risque qu'une graine binaire classique. Demandez ce chiffre quand on vous dit qu'une distribution est amorçable. La gouvernance open source a été chargée cette année, du vote de Debian sur les contributions assistées par IA à la dissolution de l'équipe centrale de Nixpkgs. Voilà un rappel que la chaîne de compilation mérite aussi de l'attention.