La porte dérobée de `xz` détectée grâce à NixOS et aux builds reproductibles

• En mars 2024, une porte dérobée a été découverte dans le logiciel xz, utilisé dans les distributions Linux pour décompresser des tarballs source.
• Cette porte dérobée a été insérée discrètement pendant trois ans par un mainteneur malveillant, Jia Tan.
• L’incident a eu un impact majeur, car il permettait l’exécution de code à distance et était extrêmement difficile à détecter.
• Elle a été découverte par hasard par Andres Freund, développeur Postgres chez Microsoft, alors qu’il enquêtait sur une baisse de performances, évitant ainsi une catastrophe majeure.

Fonctionnement de l’attaque

• La porte dérobée détournait le programme ssh pour permettre l’exécution de code à distance.
• Elle modifiait la fonction RSA_public_decrypt afin de permettre à l’attaquant d’exécuter des commandes arbitraires lors d’une connexion avec une clé RSA spécifique.
• Elle se composait de deux éléments principaux :
  1. Un script qui installait un fichier objet malveillant dans le cadre du processus de build de xz.
  2. Une procédure qui hookait la fonction RSA_public_decrypt.

1. Script d’installation du fichier objet malveillant

• Le fichier objet malveillant était caché dans les fichiers de test du dépôt git de xz.
• La porte dérobée ne s’activait que dans les tarballs de release fournis par le mainteneur.

2. Procédure de hook de la fonction RSA_public_decrypt

• Elle utilisait la fonctionnalité ifunc de glibc pour forcer l’exécution de code lancé au moment du chargement dynamique.
• Lors de l’exécution de ssh, libsystemd et liblzma étaient chargées, et la porte dérobée exécutait alors du code arbitraire pendant ce processus.

Comment éviter une catastrophe comme celle de xz

• Pour renforcer la fiabilité des logiciels open source, il faut traiter à la fois les problèmes sociaux et les problèmes techniques.
• Il faut améliorer les processus de sécurité de la supply chain logicielle.

Construire les logiciels à partir de sources fiables

• L’attaque a été efficace parce que de nombreuses distributions compilaient xz à partir des tarballs fournis par le mainteneur.
• Quand c’est possible, il faut construire les logiciels à partir de la source la plus fiable.

Quand la situation le permet...

• NixOS est une distribution basée sur un modèle de gestion de paquets fonctionnel, où chaque paquet est exprimé dans Nix, un langage de programmation fonctionnel.
• NixOS a pour habitude d’utiliser des archives source générées automatiquement depuis GitHub.

Établir la confiance dans des tarballs de release non fiables

• NixOS devait utiliser des tarballs fournis par le mainteneur à l’étape de bootstrap.
• Pour renforcer la sécurité de la supply chain logicielle, il faut mettre en place certaines protections spécifiques.

1. Comparaison des sources

• Il est important de vérifier que le tarball source utilisé par la distribution est identique à celui de GitHub.
• Cependant, il arrive souvent que les tarballs de release diffèrent des sources, et ce n’est pas forcément un problème.

2. Exploiter la reproductibilité bit à bit

• Les builds reproductibles sont une propriété d’un projet logiciel qui produit les mêmes artefacts lorsqu’il est compilé deux fois dans les mêmes conditions.
• La reproductibilité bit à bit permet d’établir la confiance dans des tarballs fournis par des mainteneurs non fiables.

Conclusion

• L’affaire de la porte dérobée de xz rappelle l’importance de la sécurité de la supply chain des logiciels open source.
• Des systèmes comme NixOS peuvent renforcer leur sécurité grâce aux builds reproductibles.

[GN⁺]

Avis Hacker News

• NixOS et les builds reproductibles n’ont pas détecté la porte dérobée de xz. NixOS a distribué une build malveillante de xz, mais comme elle ne visait pas NixOS, cela n’a pas posé de problème

  • Les développeurs de NixOS ont été surpris de voir que la version malveillante de xz avait été distribuée aux utilisateurs lorsque la porte dérobée a été révélée
  • La théorie et la réalité sont différentes, et si xz a été possible, c’est à cause de problèmes du « monde réel », pas d’une faiblesse technique. Il est difficile d’admettre qu’on ne peut pas corriger le monde réel avec du logiciel

• L’auteur semble se concentrer uniquement sur cet incident. L’affaire Jiatan est un cas unique, et les défenses peuvent aussi échouer dans d’autres scénarios

  • En tant qu’utilisateur de NixOS, je pense qu’il est très probable que NixOS n’aurait pas pu l’arrêter. Sans preuve, il est insensé d’accorder sa confiance à NixOS

• NixOS n’est pas concerné, puisque la porte dérobée de xz visait RedHat et Debian. Ironiquement, la porte dérobée a été découverte par un employé de Microsoft

• L’article indique que les distributions devraient récupérer le code source directement depuis un VCS (par ex. Github) au lieu d’utiliser les tarballs traditionnels d’installation

  • Cependant, un mainteneur malveillant peut ajouter directement des blobs binaires dans le dépôt de code source
  • L’auteur laisse entendre que Github est digne de confiance, comme s’il vérifiait le code, mais en réalité Github ne vérifie pas le code

• Si l’on veut se concentrer sur un incident que NixOS aurait pu prévenir, il faut plutôt regarder l’incident CrowdStrike. Si l’on avait pu démarrer avec la configuration de la veille, la plupart des problèmes auraient pu être atténués

• NixOS compile tout depuis les sources, vérifie cryptographiquement que les sources utilisées n’ont pas été altérées, et impose des dépendances de version entre les paquets. Debian a également des builds reproductibles

  • Le problème est que le système de build n’a pas supprimé les fichiers objets précompilés avant de compiler depuis les sources. Si personne ne vérifie le code source, on peut y ajouter une porte dérobée, et ni NixOS ni aucune autre distribution ne peuvent l’empêcher

• « Aurait pu » signifie que rien n’a été prouvé, alors qu’en pratique ils l’ont bien distribué

• Excellente analyse explicative. Titre mauvais et trompeur, probablement « techniquement exact », mais au mieux au sens de « contenant une porte dérobée »

  • Cela souligne le besoin d’outils de gestion de build et leur utilisation : il faut construire explicitement un graphe de traçabilité causale montrant comment les fichiers influencent d’autres fichiers pendant le processus de build, puis mettre en place des moyens d’imposer ce graphe ou de signaler les écarts par rapport à un graphe de traçabilité antérieur

• Si la PR de Jia Tan avait été approuvée, les artefacts malveillants auraient pu arriver tout aussi facilement dans une release Github que dans un tarball. Il est difficile de comprendre en quoi les releases Github constitueraient une mesure d’atténuation de sécurité

• Le fait que le tarball de release diffère des sources

  • Si le tarball fourni par le mainteneur a été généré honnêtement à partir du code source d’origine, il est difficile de comprendre en quoi des versions différentes, etc., poseraient problème
  • Il faudrait permettre que le tarball généré puisse être produit à partir du code source lui-même, sans rien exclure, puis faire git add & commit. Même dans ce cas, il faudrait vérifier l’historique des commits, et comme cela semblait inoffensif à l’œil nu, on peut se demander comment le vérifier
  • Cela devient un problème si le tarball maintenu est généré à partir du code source du propriétaire mais n’est pas sur Github

• Il y avait plus que le simple fait de pousser un fichier de test empoisonné, mais il est difficile de comprendre comment Nix aurait pu empêcher cela

  • Si un projet connu avait changé de responsable, il faudrait probablement examiner attentivement les commits et vérifier qui en est le responsable

• Je me demande si j’ai mal compris l’article ou si quelque chose m’a échappé