Andres Freund, un développeur Postgres, s’est rendu compte dans les derniers jours que xz et liblzma ont été corrompus par l’un des mainteneurs du projet. Le problème a été découvert par chance, pour la seule raison que la performance de sshd s’était dégradée sur sa machine.

L’investigation d’Andres Freund a montré que Jia Tan, co-mainteneur de xz depuis environ un an et demi, a poussé plusieurs commits contenant une porte dérobée extrêmement bien cachée au milieu d’un certain nombre de contributions valables depuis environ deux ans et demi, après avoir gagné la confiance du mainteneur historique, Lasse Collin.

Jia Tan a ensuite fait deux versions de xz, la 5.6.0 et 5.6.1, et les a poussées vers les mainteneurs de différentes distributions, comme Fedora Rawhide, Debian Unstable, Kali Linux ou encore Suse. Les contributions de Jia Tan à divers projets sont maintenant en cours de ré-analyse, car il apparaît qu’il a contribué des changements maintenant louches à d’autres projets, comme oss-fuzz, maintenant considérés comme visant probablement à cacher cette porte dérobée.

La plupart des distributions affectées sont des versions bleeding edge, et sont revenues à une version antérieure de leurs paquets xz.

Les effets de cette porte dérobée ne sont pas complètement analysés, mais les investigations existantes montrent des détournements d’appels très suspects autour des fonctions de validation des secrets d’OpenSSH.

Cet épisode rappelle une nouvelle fois combien tout l’écosystème repose sur la bonne volonté et la bonne foi de contributeur·rice·s volontaires, surchargé·e·s de travail, et peu soutenu·e·s par l’industrie utilisant leur travail.

NdM : le sujet est frais, les analyses en cours, et de nouvelles informations apparaissent encore toutes les heures. Il convient donc de rester prudent, mesuré, et surtout factuel, dans les commentaires. Merci d’avance.

La vieille blague de linuxfr.org IPOT prédisait que le noyau 3.2.24 ne serait plus publié au format bz2, rendant la décompression de l'archive impossible avec les moyens de 2001. Cela fait un moment que les noyaux sont publiés en tar.gz, tar.bz2 et tar.xz, on apprend maintenant que les prochaines versions du noyau seront publiées uniquement en tar.gz et tar.xz. La prochaine révision longterm 3.2.54 sera donc l'une des toutes premières affectées, la différence étant d'un seul caractère avec la prédiction d'IPOT.

Plus sérieusement, je me demande quelles options de compression seront utilisées. En effet dans le cas de la compression .xz, les besoins en mémoire augmentent considérablement pour les niveaux compressions les plus élevés (source man xz) :

(traduction) « L'utilisation de mémoire avec xz varie de quelques kilooctets à plusieurs gigaoctets, en fonction de paramètres de compressions. […] Le décompresseur aura typiquement besoin de 5% à 20% de la mémoire nécessaire au compresseur pour créer le fichier. […] Cependant, il arrive que des fichiers .xz requièrent plusieurs gigaoctets de mémoire pour être décompressés. »

(texte original) « The memory usage of xz varies from a few hundred kilobytes to several gigabytes depending on the compression settings. […] Typically the decompressor needs 5 % to 20 % of the amount of memory that the compressor needed when creating the file. […] Still, it is possible to have .xz files that require several gigabytes of memory to decompress. »

NdM : merci à JGO pour son journal.

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [Silicon] Cyber Resilience Act: l'open source en ordre de bataille
• [Ars Technica] German state gov. ditching Windows for Linux, 30K workers migrating
• [LeMagIT] La découverte de la porte dérobée XZ révèle une attaque de la chaîne logistique Linux