PROJET AUTOBLOG


Korben

Site original : Korben

⇐ retour index

Une backdoor bien critique découverte dans xz Utils / liblzma

vendredi 29 mars 2024 à 22:36

Aïe aïe aïe, ça sent le roussi ! Une vilaine backdoor a été dénichée dans l’utilitaire xz Utils, un outil de compression présent dans un paquet de distributions Linux. Et attention, c’est du lourd : cette saloperie est capable de contourner l’authentification SSH et donc de permettre un accès non autorisé aux systèmes. Autant vous dire que c’est la panique générale !

La faille a été découverte le 29 mars 2024 par un dénommé Andres Freund, un développeur qui a flairé l’embrouille dans les versions 5.6.0 et 5.6.1 de xz Utils dont la liblzma. La backdoor se planque dans les fichiers de test bad-3-corrupt_lzma2.xz et good-large_compressed.lzma, et utilise un script appelé par build-to-host.m4 pour s’incruster dans le processus de build. Cerise sur le gâteau, elle exploite le mécanisme IFUNC de la glibc pour détourner l’authentification d’OpenSSH à l’exécution. Machiavélique !

En fait, le code malveillant ne se trouve pas directement dans le dépôt mais uniquement dans les archives de release 5.6.0 et 5.6.1. Un examen du code source ne révèle donc rien de suspect, il faut télécharger les tarballs pour chopper la version vérolée. Vicieux !

Mais le plus dingue dans l’histoire, c’est que cette backdoor a été commitée par un certain JiaT75, aka Jia Tan, l’un des deux principaux développeurs de xz Utils, qui bosse sur le projet depuis 2022 ! En fait, ce type a commencé par introduire une vulnérabilité dans libarchive en 2021 avant de s’attaquer à xz.

Quand des problèmes sont apparus avec Valgrind sur la liblzma juste après la release 5.6.0 en février, ce cher Jia Tan a suggéré qu’il s’agissait d’un bug de GCC. Il a même poussé un commit bidouillant le code pour contourner les erreurs Valgrind, en pointant vers un rapport de bug GCC n’ayant rien à voir. À ce stade, il n’y a plus de doute possible : le compte JiaT75 est contrôlé par un acteur malveillant, point barre. Reste à savoir si Jia Tan a toujours été un méchant ou si son compte a été compromis.

Depuis son entrée en scène, JiaT75 n’a pas chômé. Infrastructure de test vérolée, prise de contrôle progressive du projet, jusqu’à tenter de refiler la version backdoorée à Debian, Fedora et Ubuntu. Un certain Hans Jansen, dont le compte semble avoir été créé spécialement pour ça, a même ouvert une pull request pour intégrer le code malveillant ! Et dire que GitHub a attendu le dernier moment pour mettre le grappin sur JiaT75 et bloquer l’accès au dépôt, bien joué les gars. Ils ont même suspendu le compte de Lasse Collin, le mainteneur principal.Heureusement qu’Andres veillait au grain, sinon on n’imagine même pas le bordel.

Parce que oui, ces versions 5.6.0 et 5.6.1 ont failli se faufiler dans les releases stables des principales distribs. Par chance, elles ne se sont glissées que dans quelques bêtas, notamment Fedora 40, Fedora Rawhide et les distribs testing, unstable et experimental de Debian. Même Arch Linux y a eu droit dans une release stable. Bref, ça a failli faire très mal !

Comme le souligne Will Dormann, un analyste en sécu chez Analygence, si la backdoor n’avait pas été repérée à temps, ça aurait pu être une véritable hécatombe. Les systèmes les plus à risque sont ceux qui tournent avec glibc et xz 5.6.0 ou 5.6.1, surtout s’ils exposent un serveur SSH public. Là c’est défcon 1, faut mettre à jour TOUT DE SUITE MAINTENANT ! Pour les autres, pas de panique, mais mieux vaut jouer la prudence et updater fissa. Plus d’infos sur les systèmes touchés et comment les patcher dans cet article.

Mais qu’est-ce que SSH vient faire dans cette galère ? En fait, beaucoup de distribs Linux patchent sshd pour ajouter des fonctionnalités systemd, et libsystemd utilise la liblzma. Résultat, le code d’initialisation de liblzma est exécuté au démarrage de sshd. Et devinez quoi ? La backdoor vérifie si le programme lancé est /usr/bin/sshd et remplace des fonctions comme RSA_public_decrypt, utilisée pour valider les clés SSH. On vous laisse imaginer la suite… Une analyse complète est en cours, attendez-vous à d’autres révélations dans les prochains jours.

Depuis, c’est le branle-bas de combat. Les mainteneurs de Fedora et Debian se sont empressés de retirer les versions vérolées et de revenir à une release clean de xz Utils. Et les utilisateurs sont appelés à vérifier s’ils sont affectés en utilisant un script de détection mis à dispo par Andres himself. Mais le mal est fait et la confiance est ébranlée.

L’avenir du projet xz est incertain et il faut s’attendre à un ou plusieurs hard forks et à un gros nettoyage. Pour plus d’infos, jetez un œil aux alertes de sécurité de Redhat et Debian, ainsi qu’au thread oss-security sur le sujet.

Cet épisode rappelle cruellement qu’en matière de sécurité, la vigilance est mère de sûreté, même au sein des projets open source. Il met aussi en lumière la fragilité de notre écosystème, où des pans entiers reposent sur les épaules fatiguées de quelques mainteneurs débordés. Il est grand temps d’avoir une prise de conscience collective et de mieux soutenir ces projets critiques. Parce que mine de rien, on parle quand même des fondations qui font tourner une bonne partie d’Internet et des infrastructures critiques.