Porte dérobée dans XZ Utils (CVE-2024-3094)

Le 29 mars 2024, l'ingénieur de Microsoft Andres Freund a annoncé sur la liste de diffusion oss-security qu'il avait découvert une porte dérobée délibérément implantée dans XZ Utils, une bibliothèque de compression de données quasi omniprésente dont le composant liblzma est lié par d'innombrables programmes Linux — y compris, indirectement, le sshd d'OpenSSH sur plusieurs distributions. Référencée CVE-2024-3094 avec le score CVSS maximal de 10,0, la porte dérobée était l'aboutissement d'une campagne d'ingénierie sociale pluriannuelle visant à prendre le contrôle d'un projet open source critique. Elle a été découverte par hasard, quelques jours avant que les versions compromises n'atteignent des versions stables largement déployées.

Comment elle a été découverte

Freund, développeur de PostgreSQL, a remarqué que les connexions SSH prenaient environ une demi-seconde de plus que prévu et que les processus sshd consommaient une quantité inhabituelle de CPU. Le profilage a relié ce surcoût à liblzma. En enquêtant davantage, il a mis au jour du code obfusqué qui s'accrochait au chemin de résolution de symboles utilisé par sshd, permettant à un attaquant détenant une clé privée Ed448 spécifique d'obtenir une exécution de code à distance en envoyant une charge d'authentification forgée — une porte dérobée distante quasi invisible, verrouillée par clé.

Le jeu de longue haleine

La porte dérobée n'était pas un commit isolé. À partir de 2021 environ, un personnage de mainteneur nommé « Jia Tan » (JiaT75) a bâti sa crédibilité dans la communauté XZ Utils par des contributions légitimes. En 2022–2023, un concert de comptes fantoches apparents a poussé le mainteneur d'origine surchargé à céder ses responsabilités, et Jia Tan s'est finalement vu accorder l'autorité de commit et de publication.

La charge malveillante a ensuite été introduite par étapes. Le code dangereux n'était pas présent dans le dépôt Git lisible par l'humain ; il était au contraire dissimulé dans des fichiers « de test » binaires déguisés et activé par un build-to-host.m4 modifié qui n'existait que dans les archives de publication. Lors de la compilation sur les systèmes Linux x86-64 utilisant glibc et GCC, la logique de build extrayait et injectait l'objet malveillant dans liblzma — garantissant qu'une revue ordinaire du code source de l'arbre Git ne le révélerait pas.

Impact et confinement

• Les versions affectées étaient XZ Utils 5.6.0 (24 février 2024) et 5.6.1 (9 mars 2024).
• La porte dérobée a atteint les branches de développement et de test de Fedora Rawhide/40-bêta, Debian unstable/testing, Kali Linux et Arch Linux — mais la plupart des versions stables de production n'avaient pas encore livré les versions compromises.
• La CISA a exhorté à revenir à une version saine connue telle que la 5.4.6 ; Red Hat, SUSE et Debian ont rétabli les paquets le jour de la divulgation ; Canonical a reporté la bêta d'Ubuntu 24.04 LTS par précaution.
• Une 5.6.2 saine a été publiée en mai 2024. Aucune exploitation confirmée en conditions réelles contre des systèmes de production n'a été établie, la découverte ayant devancé un déploiement à grande échelle.

Pourquoi c'est important

XZ Utils est le cas emblématique de la subversion de la chaîne d'approvisionnement open source par la confiance, et non par l'exploitation technique. L'attaquant n'a pas compromis un serveur ; il s'est frayé un chemin par ingénierie sociale jusqu'au statut de mainteneur d'une bibliothèque fondamentale et a militarisé le pipeline de build afin que la porte dérobée n'apparaisse jamais dans le code source révisé. Sa découverte a tenu à un seul ingénieur remarquant une demi-seconde de latence — un rappel inquiétant de l'étroitesse de la marge. L'incident a catalysé des changements durables : un examen attentif de l'épuisement des mainteneurs et des projets à mainteneur unique, des initiatives de financement pour les infrastructures open source critiques, une adoption plus large des builds reproductibles et de la comparaison archive-contre-dépôt, et une attention renouvelée à l'hypothèse selon laquelle « de nombreux yeux » rendraient automatiquement sûr le code open source.