Revue de presse de l’April pour la semaine 16 de l’année 2024

14
23
avr.
2024
Internet

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.

Revue de presse de l’April pour la semaine 14 de l’année 2024

13
9
avr.
2024
Internet

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.

XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois

107
31
mar.
2024
Sécurité

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.

Journal Xz (liblzma) compromis

96
29
mar.
2024

Bonjour à tous,

La nouvelle que le projet xz (et en particulier liblzma) a été compromis vient de tomber. Donc avant de lire la suite, commencez par vous assurer que vous n'ayez aucune installation de xz version 5.6.0 ou 5.6.1 installée sur vos systèmes pour corriger cette porte dérobée, particulièrement si vous êtes avec un debian ou dérivée. Debian a une version corrigée "5.6.1+really5.4.5-1", Arch Linux une version 5.6.1-2.

Tous les détails de la faille de sécurité sont donnés là (…)

Les nouvelles versions du noyau seront publiées en .xz

Posté par  . Édité par Benoît Sibaud, ariasuni, Ontologia et Florent Zara. Modéré par Bruno Michel. Licence CC By‑SA.
Étiquettes :
24
31
déc.
2013
Noyau

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.