Principe de l'attaque

Le trusting‑trust attack décrit par Ken Thompson repose sur un compilateur corrompu qui insère un cheval de Troie dans chaque binaire qu’il génère, puis se réplique dans ses propres reconstructions. Les auteurs de l’étude démontrent que le même principe s’applique à un outil de post‑compilation : GNU strip. En modifiant uniquement le binaire de strip présent dans le binary seed de NixOS, ils injectent un payload capable de se propager d’une génération de strip à la suivante, sans toucher au code source.

Mécanisme de propagation via GNU strip

Le vecteur d’infection exploite le fait que strip ne lit pas le code source mais manipule directement les fichiers ELF. L’équipe a ajouté une section personnalisée contenant le code malveillant à l’aide d’objcopy :

objcopy --add-section .payload=payload.bin $(which strip) $(which strip).infected

Le binaire infecté remplace le strip original dans le graphe de dépendances du bootstrap NixOS. Lors de chaque étape de construction, strip reçoit un ELF déjà contaminé, y ajoute la même section .payload et le redistribue. Cette boucle de rétroaction garantit que le cheval de Troie persiste même après que le seed initial a quitté la clôture de dépendance.

Sur une révision réelle de nixpkgs, le processus a produit un installateur graphique complet, sans erreur de compilation, tout en insérant le payload dans presque tous les binaires générés. Le résultat est un environnement standard où chaque paquet peut être contrôlé à distance par l’attaquant.

Conséquences pour la chaîne d'approvisionnement et limites

Cette démonstration élargit la surface d’attaque de la chaîne d’approvisionnement au-delà des compilateurs. Les outils de post‑traitement, souvent considérés comme « neutres », peuvent devenir des vecteurs de compromission lorsqu’ils sont intégrés dans des processus de bootstrap automatisés. La vulnérabilité repose sur deux faits concrets : (1) la confiance implicite accordée aux binaires pré‑compilés du seed, et (2) l’absence de vérification d’intégrité des transformations ELF appliquées par strip.

Les contre‑mesures proposées incluent la signature cryptographique de chaque binaire d’outil, la validation de l’empreinte ELF avant chaque exécution de strip, et la limitation de la portée du seed à des paquets strictement nécessaires. Cependant, l’étude souligne que la plupart des distributions Linux ne disposent pas d’un tel mécanisme de traçabilité, ce qui rend l’attaque réalisable à grande échelle.

En conclusion, l’expérimentation montre que la confiance aveugle dans les utilitaires de construction, même ceux qui ne génèrent pas de code source, constitue une faille critique. La communauté doit réévaluer les modèles de confiance implicite et envisager des architectures de bootstrap où chaque étape est auditée cryptographiquement, afin de prévenir la récurrence d’un trusting‑trust à l’échelle d’une distribution entière.