URL: https://linuxfr.org/news/xz-et-liblzma-faille-de-securite-volontairement-introduite-depuis-au-moins-deux-mois Title: XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois Authors: Colin Leroy Benoît Sibaud et Ysabeau 🧶 🧦 Date: 2024-03-30T11:33:59+01:00 License: CC By-SA Tags: xz, porte_dérobée, lzma, sécurité et chaine_d'approvisionnement Score: 6 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. ---- [Le courriel publiant la faille sur Openwall.com](https://www.openwall.com/lists/oss-security/2024/03/29/4) [FAQ on the xz-utils backdoor](https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27) [L'alerte pour Fedora](https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users) [L'alerte pour Debian](https://lists.debian.org/debian-security-announce/2024/msg00057.html) [L'alerte pour Kali](https://infosec.exchange/@kalilinux/112180505434870941) [Une Pull Request suspecte sur le projet oss-fuzz](https://github.com/google/oss-fuzz/pull/10667) [L'alerte pour openSUSE](https://news.opensuse.org/2024/03/29/xz-backdoor/) [L'alerte pour Arch Linux](https://archlinux.org/news/the-xz-package-has-been-backdoored/) [Réaction du projet XZ](https://tukaani.org/xz-backdoor/) ---- Les infos qui suivent ont été ajoutées en modération (le sujet ayant été discuté en [lien](https://linuxfr.org/users/misc/liens/backdoor-in-upstream-xz-liblzma-leading-to-ssh-server-compromise) et en [journal](https://linuxfr.org/users/ytterbium/journaux/xz-liblzma-compromis) précédemment) : - autres sites discutant du sujet : * [liste des dév Fedora](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IJRW6X34BBJQLAQ64G53S7XPRU35U7KN/) (anglais) * [news.ycombinator.com](https://news.ycombinator.com/item?id=39865810) (en anglais) * [Lobsters](https://lobste.rs/s/uihyvs/backdoor_upstream_xz_liblzma_leading_ssh) * [Linux Weekly News](https://lwn.net/Articles/967180/) * [Python](https://discuss.python.org/t/cpython-pypi-and-many-python-packages-are-not-affected-by-the-backdoor-of-xz/49873) : _CPython, PyPI, and many Python packages are not affected by the backdoor of xz_ (CPython, PyPI, et beaucoup de paquets Python packages ne sont pas concernés par la porte dérobée sur xz) - des résumés / suivis : - [boehs.org](https://boehs.org/node/everything-i-know-about-the-xz-backdoor) - [lcamtuf.substack.com](https://lcamtuf.substack.com/p/technologist-vs-spy-the-xz-backdoor) - explication en image (et en anglais) par Thomas Roccia sur X : ![XZ Outbreak CVE-2024-3094 par Thomas Roccia](https://pbs.twimg.com/media/GJ-6mD9aIAARaiY?format=jpg&name=900x900) - une [FAQ](https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27#misc-notes) - des analyses du code injecté : - [@filippo.abyssdomain.expert ](https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b) - [ @smx-smx smx-smx/XZ Backdoor Analysis](https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504) - quelques commentaires techniques : - [Misc](https://linuxfr.org/users/misc/liens/backdoor-in-upstream-xz-liblzma-leading-to-ssh-server-compromise#comment-1954781): _pam_ charge à la volée ses modules (mais aucun ne semble dépendre de liblzma sur ma machine) et [libsystemd aussi depuis 1 mois](https://github.com/systemd/systemd/commit/3fc72d54132151c131301fc7954e0b44cdd3c860), comme l'a souligné Lennart Poettering sur HackerNews - [roger21](https://linuxfr.org/users/misc/liens/backdoor-in-upstream-xz-liblzma-leading-to-ssh-server-compromise#comment-1954824) : la commande _ldd_ n'est pas sûre sur un binaire à la fiabilité incertaine