- Pendant plus de 2 ans, l’attaquant utilisant le nom de « Jia Tan » a agi comme un contributeur sérieux et efficace à la bibliothèque de compression xz, obtenant finalement les droits de commit et les droits d’administration.
- Il a utilisé ces droits pour installer une porte dérobée extrêmement subtile et soigneusement dissimulée dans
liblzma, qui fait partie de xz et constitue aussi une dépendance de sshd d’OpenSSH sur Debian, Ubuntu, Fedora et d’autres systèmes Linux basés sur systemd.
- Cette porte dérobée surveillait l’envoi par l’attaquant de commandes cachées au démarrage d’une session SSH, lui permettant d’exécuter des commandes arbitraires sur le système cible sans même se connecter. Il s’agit d’une exécution de code à distance non authentifiée sur la cible.
- L’attaque a été rendue publique le 29 mars 2024 et semble être la première attaque sérieuse de la chaîne d’approvisionnement visant un logiciel open source largement utilisé.
- Il s’agit d’un événement charnière pour la sécurité de la chaîne d’approvisionnement open source.
- Ce billet est une chronologie détaillée des aspects d’ingénierie sociale de cette attaque, qui semble remonter à la fin de 2021.
Prologue
- Entre 2005 et 2008, Lasse Collin, avec l’aide d’autres personnes, a conçu le format de fichier
.xz en utilisant l’algorithme de compression LZMA, qui compresse les fichiers à environ 70 % de la taille obtenue avec gzip.
- Avec le temps, ce format a été largement utilisé pour compresser les fichiers
tar, les images du noyau Linux, etc.
L’arrivée de Jia Tan et de ses soutiens
- 2021-10-29 : Jia Tan envoie son premier patch anodin à la mailing list
xz-devel.
- 2021-11-29 : Jia Tan envoie un deuxième patch anodin.
- 2022-04-19 : Jia Tan envoie un autre patch anodin.
- 2022-04-22 : « Jigar Kumar » se plaint que les patchs de Jia Tan n’ont toujours pas été fusionnés.
- 2022-05-19 : « Dennis Ens » demande quel est l’état de la maintenance de XZ for Java.
- 2022-05-19 : Lasse Collin s’excuse de sa lenteur à répondre et explique que « Jia Tan aide hors liste sur XZ Utils et pourrait au minimum y prendre un rôle plus important ».
- 2022-05-27 : Jigar Kumar envoie un e-mail de pression dans le fil du patch.
- 2022-06-07 : Jigar Kumar envoie un e-mail de pression dans le fil Java.
- 2022-06-08 : Lasse Collin répond qu’il n’a pas perdu intérêt, mais qu’il est limité par des problèmes de santé mentale.
- 2022-06-10 : Lasse Collin fusionne le premier commit écrit par Jia Tan.
- 2022-06-14 : Jugar Kumar envoie un autre e-mail de pression.
- 2022-06-21 : Dennis Ens envoie un e-mail de pression suggérant de confier la maintenance à quelqu’un d’autre.
- 2022-06-22 : Jigar Kumar envoie un e-mail de pression dans le fil du patch C.
- 2022-06-29 : Lasse Collin répond en laissant entendre que « Jia Tan pourrait prendre un rôle plus important dans le projet ».
Jia Tan devient mainteneur
- Lasse semble avoir commencé à travailler plus étroitement avec Jia Tan. Jigar Kumar et Dennis Ens sont très probablement des personnages fictifs.
- 2022-09-27 : Jia Tan fournit un résumé de la publication 5.4.0.
- 2022-11-30 : Lasse Collin modifie l’adresse des e-mails de rapport de bug, passant de son adresse personnelle à un alias partagé avec Jia Tan.
- 2022-12-30 : Jia Tan fusionne directement son premier commit dans le dépôt xz.
- 2023-01-11 : Lasse Collin tague et construit
v5.4.1, sa dernière publication.
- 2023-03-18 : Jia Tan tague et construit
v5.4.2, sa première publication.
- 2023-03-20 : Jia Tan met à jour la configuration de Google
oss-fuzz afin que les bugs lui soient envoyés.
- 2023-06-22 : Hans Jansen envoie une paire de patchs utilisant la fonctionnalité « GNU indirect function » ; Lasse Collin les retravaille puis Jia Tan les fusionne.
- 2023-07-07 : Jia Tan désactive la prise en charge de
ifunc pendant les builds oss-fuzz.
- 2024-01-19 : Jia Tan déplace le site web vers GitHub Pages et prend le contrôle de la page web de XZ Utils.
Début de l’attaque
- 2024-02-23 : Jia Tan fusionne du code binaire de porte dérobée caché dans des fichiers d’entrée de test.
- 2024-02-24 : Jia Tan tague
v5.6.0 et publie l’archive de distribution xz-5.6.0.tar.gz, qui inclut le fichier malveillant build-to-host.m4.
- 2024-02-24 : Des crashs commencent à apparaître sur Gentoo avec la version 5.6.0.
- 2024-02-26 : Debian ajoute
xz-utils 5.6.0-0.1 à unstable.
- 2024-02-28 : Debian ajoute
xz-utils 5.6.0-0.2 à unstable.
- 2024-02-29 : Sur GitHub,
@teknoraver soumet une pull request pour empêcher liblzma d’être liée à libsystemd.
- 2024-02-28 : Jia Tan ajoute une faute de frappe subtile dans le programme C utilisé pour vérifier la prise en charge de Landlock, cassant ainsi la détection de Landlock par le script
configure.
- 2024-03-04 : Des erreurs Valgrind commencent à apparaître sur les distributions RedHat dans
_get_cpuid de liblzma.
- 2024-03-05 : La PR
libsystemd est fusionnée et liblzma est retirée.
- 2024-03-05 : Debian ajoute
xz-utils 5.6.0-0.2 à testing.
- 2024-03-05 : Jia Tan commit un correctif du bug
ifunc.
- 2024-03-08 : Jia Tan effectue un commit pour un correctif Valgrind.
- 2024-03-09 : Jia Tan effectue un commit mettant à jour les fichiers de la porte dérobée.
- 2024-03-09 : Jia Tan tague
v5.6.1 et publie la distribution xz 5.6.1.
- 2024-03-20 : Lasse Collin envoie sur la LKML une série de patchs ajoutant son nom et celui de Jia Tan comme mainteneurs du code de compression xz du noyau.
- 2024-03-25 : Hans Jansen ouvre un bug Debian pour mettre à jour
xz-utils vers 5.6.1.
- 2024-03-28 : Jia Tan ouvre un bug Ubuntu pour faire passer
xz-utils à 5.6.1 depuis Debian.
Détection de l’attaque
- 2024-03-28 : Andres Freund découvre le bug et alerte Debian ainsi que
distros@openwall en privé. RedHat attribue CVE-2024-3094.
- 2024-03-28 : Debian revient en arrière sur 5.6.1 et introduit
5.6.1+really5.4.5-1.
- 2024-03-29 : Andres Freund publie sur la liste publique
oss-security@openwall une alerte sur la porte dérobée, indiquant l’avoir découverte « au cours des dernières semaines ».
- 2024-03-29 : RedHat annonce que des versions de xz contenant la porte dérobée ont été distribuées dans Fedora Rawhide et la bêta de Fedora Linux 40.
- 2024-03-30 : Debian arrête les builds et reconstruit les machines de build à partir de Debian stable.
L’avis de GN⁺
- Cet incident sera un tournant majeur pour les attaques de la chaîne d’approvisionnement visant les logiciels open source, car les complices ont gagné la confiance sur une longue période par l’ingénierie sociale, ont obtenu des droits d’accès, puis ont discrètement installé une porte dérobée dans une bibliothèque centrale largement utilisée.
- Il est nécessaire de repenser la gouvernance des projets open source et les processus de délégation des droits. Il pourrait être pertinent d’envisager des modèles de gouvernance plus distribués afin qu’un projet ne dépende pas de la situation personnelle d’un mainteneur clé.
- Les audits de sécurité et les revues de code des grands projets open source vont devenir encore plus importants. Il faut aussi des outils de vérification automatisés pour détecter les changements suspects et empêcher l’abus de privilèges, par exemple des alertes lors de l’ajout de données binaires.
- Sans remettre en cause les avantages du modèle open source, où le développement est public et où chacun peut contribuer, il faudra mettre en place des dispositifs techniques et institutionnels capables d’identifier les contributeurs malveillants et de bloquer les attaques plus tôt.
- Les projets open source qui utilisent des langages ou des outils peu sûrs seront encore plus exposés. En plus d’efforts multiformes pour améliorer la sécurité — sûreté mémoire, analyse statique, fuzzing — une transition vers des outils plus modernes sera aussi nécessaire.
- L’attention va se concentrer sur l’analyse détaillée des conditions d’activation cachées de la porte dérobée, de son mode de diffusion et de son périmètre d’impact. On pourra en tirer des enseignements pour se défendre contre des attaques similaires à l’avenir.
7 commentaires
Ce qui m’inquiète à cause de cette affaire, c’est que…
On pourrait pirater le PC d’un développeur open source, ou l’enlever / le séquestrer, ou encore l’acheter avec de l’argent pour y implanter du code malveillant…
Et quand je pense à l’argent, ça me fait aussi me demander si les développeurs open source vivent correctement ?
Je travaille dans la sécurité, et quand on trouve un bug en faisant une code review, il y a toujours quelqu’un pour lâcher une vanne du genre : « Quoi, tu as été embauché ici il y a 5 ans juste pour pouvoir glisser ce code ? » lol
Lesser Collin en a sans doute bavé à bien des égards...
Oui, Arch Linux a été corrigé depuis belle lurette~ venez, venez, hop backdoor out, le dernier Arch c’est du lourd~
pacman -SyuLasse Collin a publié un article récapitulant cette affaire.
https://tukaani.org/xz-backdoor/
Avis Hacker News
Excellente synthèse de l’incident, avec tous les liens rassemblés au même endroit, ce qui en fait une ressource parfaite pour quiconque veut comprendre comment une attaque d’ingénierie sociale se déroule en pratique.
Souligne l’absence de la chronologie Fedora.
Estime qu’il ne faut plus tolérer du code difficile à comprendre dans les systèmes.
Cela pourrait être l’une des conséquences positives, avec une attitude plus conservatrice vis-à-vis des mises à niveau.
Suggère qu’au sein de la communauté FOSS, on pourrait soit bannir systématiquement les utilisateurs impolis, soit provoquer un changement culturel en sensibilisant davantage la communauté afin de réagir plus fermement aux comportements grossiers.
Fait remarquer que l’observation sur le format des adresses e-mail est erronée.
Exprime son inquiétude face à la facilité avec laquelle la pression sociale pousse les gens à abandonner le contrôle.
En tant que mainteneur, souligne que plus un contributeur ou un utilisateur insiste avec acharnement, moins il est probable que sa demande soit acceptée.
Cite l’avis de Joe Cooper et partage son point de vue sur la pression exercée sur les mainteneurs de projet.
Explique que le code binaire de la porte dérobée cachée est très bien dissimulé dans des fichiers binaires d’entrée de test, et que comme ces fichiers ont pour la plupart été créés à la main avec un éditeur hexadécimal, les fichiers eux-mêmes constituent le meilleur « code source ».