Dans les dernières nouvelles publiées juste après la mise en ligne de notre chronique hebdomadaire sur la sécurité, une porte dérobée a été découverte dans le package xz, qui pourrait potentiellement compromettre les connexions SSH sur les systèmes Linux. L'analyse la plus détaillée jusqu'à présent semble être celle de [Andres Freund] sur la liste oss-security.
Les archives tar de la version xz de la version 5.6.0 fin février et de la version 5.6.1 du 9 mars contiennent toutes deux du code malveillant. Une paire de fichiers compressés dans le référentiel contient la majorité du correctif malveillant, déguisé en fichiers de test. En pratique, cela signifie que regarder le référentiel ne révèle rien d'anormal, mais télécharger les archives tar de la version vous donne le code compromis.
Cela a été découvert parce que les connexions SSH sur un côté Debian prenaient plus de temps, avec plus de cycles CPU que prévu. Et ce qui est intéressant, c'est que Valgrind provoquait des erreurs inattendues lors de son exécution sur la bibliothèque liblzma. Ce dernier élément a été découvert pour la première fois le 24 février, immédiatement après la version 5.6.0. Le package xz-utils a échoué à ses tests sur les versions Gentoo.
L'un des responsables de xz, [Jia Tan], a pesé sur ce bug Gentoo, suggérant qu'il s'agissait d'un bug GCC à l'origine des erreurs Valgrind. Il s’agit du même développeur qui a poussé les fichiers d’archives malveillants et créé les versions corrompues. Et comme pour dissiper tous les doutes restants, le développeur a redoublé d'efforts dans un commit GitHub, en contournant les erreurs Valgrind et en créant un lien vers un rapport de bogue GCC totalement indépendant affirmant qu'il s'agissait de ce problème.
À ce stade, la seule conclusion raisonnable est que la personne qui contrôle le [JiaT75] Le compte GitHub est un acteur malveillant et n’est absolument pas digne de confiance. Ce qui n'est pas clair, c'est s'il s'agit toujours du même développeur qui co-maintient le projet depuis août 2022. Il est possible que [Jia Tan] a toujours été un mauvais acteur, ou ce compte pourrait être complètement compromis.
Et SSH ?
Ce qui n'est peut-être pas clair, c'est la connexion à SSH. Et c'est un voyage. De nombreuses distributions Linux corrigent sshd pour ajouter des fonctionnalités systemd, et libsystemd extrait la bibliothèque liblzma. Cela signifie que le code d'initialisation de liblzma est exécuté au démarrage de sshd. Dans le code malveillant, la bibliothèque vérifie argv[0]qui est le nom du programme en cours d'exécution, par exemple /usr/bin/sshd. De plus, il semble vérifier les outils de débogage comme rr et gdb. Si les coches sont vertes, liblzma remplace quelques appels de fonction par son propre code. C'est une danse compliquée, mais l'exploit cherche spécifiquement à remplacer RSA_public_decrypt.
C'est une fonction très intéressante à écraser, car c'est l'une des fonctions utilisées pour valider les clés SSH. Il n'est pas difficile d'imaginer comment un code malveillant pourrait rechercher une signature magique et contourner le processus de connexion normal. L’analyse complète est toujours en cours et nous attendons plus d’informations dans les prochains jours.
Mais l’essentiel est qu’une machine avec un binaire sshd corrigé, qui possède également les packages xz version 5.6.0 ou 5.6.1, est vulnérable aux connexions SSH non authentifiées. La bonne nouvelle est que seules quelques distributions ont livré la série 5.6.x de packages xz. Fedora Rawhide/41 et Debian Testing et Unstable ont également livré ces versions. Si vous utilisez un système concerné, recherchez immédiatement une mise à jour.
On ne sait pas quelle est la voie à suivre pour le projet xz. Il s’agit évidemment d’un utilitaire système important pour les systèmes Linux, et ses responsables actuels semblent dormir au volant – ou se diriger intentionnellement vers le désastre. Attendez-vous à un ou plusieurs hard forks, puis à beaucoup de travail de nettoyage.
Ceci est une histoire en développement. Pour en savoir plus, consultez l'alerte de sécurité Redhat, l'alerte Debian et le fil de discussion oss-security sur le sujet.
