La porte dérobée XZ CVE-2024-3094

Le 29 mars 2024, un acteur malveillant a mené une campagne prolongée et fortement investie visant à implanter une porte dérobée dans la bibliothèque logicielle Linux liblzma afin d’accéder à plusieurs systèmes d’exploitation via des distributions Linux — et a presque réussi, jusqu’à ce qu’un ingénieur curieux remarque une anomalie.

Logiciels en amont actuellement connus comme étant affectés et mesures d’atténuation proposées :

Qu’est-ce que XZ ?

XZ, également connu sous le nom de XZ Utils, fournit une interface en ligne de commande pour les fonctions de compression et de décompression. Il est souvent intégré aux distributions Linux, comme Debian, Ubuntu et bien d’autres.

// Example usage of XZ for context:
$ xz llm_rag_context.json

// Results in a new compressed file on disk:
$ ls -al llm_tag_context.json.xz
.rw-r--r--   81k lirantal 31 Mar 10:29   -N  llm_tag_context.json.xz

Qu’est-ce que Liblzma ?

Liblzma est la bibliothèque logicielle qui implémente l’algorithme de compression et de décompression LZMA et fournit des liaisons logicielles permettant à d’autres langages de programmation de l’utiliser, comme le programme CLI xz.

Qu’est-ce que CVE-2024-3094 ?

L’identifiant de vulnérabilité CVE-2024-3094 a été publié le 29 mars 2024 pour signaler une gravité critique de 10,0 dans le package liblzma.

Le rapport CVE attribue le risque de sécurité à du code malveillant découvert dans la bibliothèque logicielle liblzma. Celui-ci permettait de modifier les données lors de leur traitement par le code de la bibliothèque, entraînant une perte d’intégrité susceptible d’avoir des conséquences encore plus graves.

Quelles sont les conséquences de la porte dérobée XZ ?

Le protocole SSH et ses outils associés sous Linux permettent l’accès à distance entre des hôtes. La porte dérobée XZ permettant l’interception et la modification des données, et certaines distributions Linux mettant liblzma à disposition du programme SSH, on peut supposer dans un premier temps que CVE-2024-3094 pourrait permettre de contourner l’authentification dans le programme sshd.

En termes simples, une personne disposant d’une clé RSA pourrait s’authentifier à distance auprès de tout serveur SSH ouvert et doté de la porte dérobée.

On suppose désormais que la porte dérobée XZ pourrait permettre l’exécution de code à distance. Une enquête est toutefois en cours pour analyser le code de la porte dérobée implanté dans liblzma et retracer toutes les contributions effectuées par l’acteur malveillant impliqué ou liées à celui-ci.

Chronologie des événements :

• Le fichier de compilation malveillant a été ajouté à xz-utils de Debian le 24 février 2024.

• La version 5.6.0 de l’archive tar xz-utils a été publiée le 24 février, et la version 5.6.1 le 9 mars 2024.

• La version 5.6.0 a été ajoutée à Fedora le 27 février 2024.

L’histoire de la porte dérobée XZ

Une grave faille de sécurité a été signalée le 29 mars 2024, lorsque Andres Freund, contributeur à la liste de diffusion oss-security d’Openwall, a révélé une possible compromission de la bibliothèque liblzma, qui fait partie du package XZ Utils largement utilisé.

Cette découverte a eu lieu après que Freund a remarqué une utilisation anormalement élevée du processeur par le processus sshd, ce qui l’a conduit à approfondir ses recherches.

Le problème provient de fichiers de test compressés et conçus de manière malveillante, intégrés aux versions 5.6.0 et 5.6.1 de liblzma. Ils visaient à créer une porte dérobée en modifiant le script configure des fichiers tar. L’exploit, bien qu’inactif dans des conditions normales, s’active sur les systèmes utilisant un correctif spécifique pour le serveur SSH. Il peut alors contourner l’authentification de sshd et donner un accès à distance non autorisé au système.

La capture d’écran suivante provient de l’analyse du logiciel malveillant XZ d’Andres, envoyée à la liste de diffusion OSS-Security d’Openwall :

Cet exploit sophistiqué s’appuie sur le mécanisme IFUNC de la bibliothèque GNU C, communément appelée glibc, pour ajouter un résolveur à la méthode crc64_resolve. Celui-ci installe un hook d’audit qui remplace la fonction RSA_public_decrypt d’OpenSSH par une version compromise. OpenSSH n’a généralement pas besoin de liblzma. Cependant, l’exploit tire parti d’un scénario de chargement en chaîne dans lequel un correctif tiers provoque le chargement de libsystemd, qui charge ensuite la bibliothèque logicielle liblzma affectée. À la date de rédaction, la porte dérobée ne touche sshd que sur un sous-ensemble de distributions Linux appliquant ce correctif pour activer les notifications de systemd

Un aspect particulièrement sournois de cette attaque réside dans l’ajout d’un fichier build-to-host.m4 modifié à l’archive tar publiée sur GitHub. Ce fichier était absent du dépôt Git et son origine ne pouvait donc pas être retracée dans le contrôle de version.

Ce fichier de compilation M4 extrait et injecte le code malveillant lors de la compilation sur des systèmes spécifiques : les plateformes x86-64 Linux utilisant glibc et GCC, et compilées avec dpkg ou rpm, des outils populaires de création de packages pour les distributions Linux Debian et Red Hat.

À la suite de cette compromission, GitHub a archivé le dépôt hébergeant XZ Utils pour violation des conditions d’utilisation. L’enquête sur l’origine de la porte dérobée pointe vers Jia Tan, responsable de la maintenance du projet xz, même si l’on ignore encore si l’acte était intentionnel ou si le compte du responsable avait été compromis. L’identité réelle associée à ce compte reste à déterminer.

Cette attaque de la chaîne d’approvisionnement a touché plusieurs distributions Linux, dont Debian 13 et unstable, Fedora Rawhide, Fedora 40, Kali Linux et OpenSUSE Tumbleweed. Arch Linux a exhorté ses utilisateurs à effectuer rapidement la mise à jour. À noter que la plupart des distributions suivant un cycle de mises à jour stable ont été épargnées, car elles utilisaient des versions antérieures et non affectées de XZ. FreeBSD n’est pas non plus touché, car il intègre des versions de XZ antérieures à l’incident et que l’attaque cible glibc sous Linux. En revanche, si vous avez automatisé le déploiement de vos images de conteneurs en utilisant les dernières mises à jour disponibles de Fedora ou Debian, vous déployez probablement le programme XZ vulnérable.

Répertorié sous le nom CVE-2024-3094 et assorti d’un score CVSS de 10, le maximum possible, cet incident souligne la gravité des enjeux de sécurité de la chaîne d’approvisionnement et la complexité des questions de confiance et de vérification des contributions open source.

Réparer les dégâts : l’opération de nettoyage de XZ

Lorsque l’affaire a éclaté, Lasse Collin, le responsable d’origine de la maintenance de la bibliothèque XZ Utils, s’est empressé de valider un correctif du code source dans la configuration de compilation de la bibliothèque. Ce diff montre le travail sournois et élaboré de l’acteur malveillant pour mener à bien sa campagne de porte dérobée. Le caractère point (.) a provoqué un échec de l’outil de compilation, qui a alors désactivé un bac à sable de sécurité et contourné les contrôles de sécurité.

Détecter la vulnérabilité XZ avec Snyk

Il existe plusieurs façons de détecter gratuitement la vulnérabilité XZ avec Snyk : à l’aide de la Snyk CLI, vous pouvez tester vos projets en local : gratuitement.

• Pour les applications, exécutez snyk test --unmanaged depuis la Snyk CLI afin d’analyser les dépendances non gérées de votre dépôt et de détecter les packages individuels ainsi que leurs vulnérabilités.

• Pour les conteneurs, exécutez snyk container test afin de détecter les packages de systèmes d’exploitation pris en charge qui dépendent de versions vulnérables de XZ.

Vous pouvez également analyser tous les projets de vos dépôts Git et obtenir un rapport sur l’ensemble des dépendances directes et transitives que vous utilisez. 

Dans ce rapport, vous verrez si vous dépendez de XZ et dans combien de chemins de votre graphe de dépendances il est utilisé. Vous pouvez également rechercher rapidement « CVE-2024-3094 » dans tous vos projets.

À la croisée de la sécurité de la chaîne d’approvisionnement et de l’open source

La porte dérobée XZ a provoqué des remous dans les communautés open source et de cybersécurité, suscitant des débats et des inquiétudes quant à l’intégrité des logiciels open source et aux risques permanents d’attaques de la chaîne d’approvisionnement. Cet incident rappelle de manière frappante la compromission de SolarWinds et les nombreux packages malveillants découverts dans des registres logiciels comme npm et PyPI. Il met en évidence une tendance aux vulnérabilités de la chaîne d’approvisionnement qui ont de profondes répercussions sur la cybersécurité mondiale.

Jia Tan, apparu sous le pseudonyme GitHub JiaT75, ainsi que des personnes associées comme Jigar Kumar et Dennis Ens, ont illustré une campagne sophistiquée menée sur plusieurs années pour intégrer du code malveillant dans XZ Utils, un utilitaire logiciel essentiel utilisé dans de nombreuses distributions Linux. D’abord constituées de contributions apparemment anodines, puis de pressions directes exercées sur les responsables de la maintenance pour obtenir un accès permettant de valider des modifications, les tactiques employées étaient habiles. Elles exploitaient à la fois des techniques d’ingénierie technique et sociale, ainsi que la confiance et la collaboration propres à la communauté open source.

Le parcours de Jia Tan au sein de XZ Utils, qui a commencé par des activités suspectes dans d’autres projets comme libarchive, brosse un tableau complexe d’actions préméditées ayant mené à la découverte de CVE-2024-3094. Ces actions, notamment la création d’une infrastructure de test et des tentatives délibérées de dissimuler l’intention malveillante en détournant les implémentations ifunc, témoignent d’un degré de préméditation et de manipulation inquiétant.

Cet incident soulève des questions cruciales sur la pérennité de la confiance et de la sécurité dans les logiciels open source. La nature même de l’open source — son ouverture et sa dépendance aux contributions de la communauté — devient son talon d’Achille lorsque des acteurs malveillants s’y infiltrent avec l’intention de nuire. L’incident met également en lumière le stress important et les difficultés de santé mentale auxquels sont confrontés les responsables de la maintenance, qui consacrent souvent bénévolement leur temps et leur expertise, sous une pression immense, pour assurer la sécurité et la mise à jour des projets.

Il est impossible d’ignorer les similitudes avec des incidents passés, comme la vaste compromission de SolarWinds ou le flot continu de packages empoisonnés dans les dépôts logiciels publics. Tous ont un point commun : l’exploitation de la confiance et la complexité des chaînes d’approvisionnement logicielles modernes. Ils rappellent avec force la sophistication des adversaires numériques et les vulnérabilités des infrastructures numériques dont nous dépendons de plus en plus.

À la lumière de CVE-2024-3094 et des précédents historiques, la communauté open source et l’ensemble du secteur technologique doivent réévaluer et renforcer les pratiques de sécurité liées au développement et à la distribution de logiciels. Il s’agit notamment d’examiner les contributions de plus près, de mettre en place des processus de vérification plus robustes pour les responsables de la maintenance et de favoriser une collaboration accrue autour des bonnes pratiques de sécurité. Il est également urgent de concevoir des modèles de financement durables pour les projets open source, afin que les responsables de la maintenance disposent des ressources et des outils nécessaires pour sécuriser efficacement leurs logiciels.

Alors que nous faisons face aux conséquences de cet incident et d’autres du même type, nous devons mener des discussions ouvertes et critiques sur l’équilibre entre la philosophie open source et les impératifs de sécurité. La résilience des logiciels open source et de l’écosystème numérique dans son ensemble dépend de notre capacité collective à nous adapter et à renforcer nos défenses contre ceux qui cherchent à les fragiliser.

Qui est Jia Tan ? S’agit-il d’une personne ou d’un acteur soutenu par un État ? Quels autres projets aurait-il pu compromettre et piéger avec une porte dérobée ? Les chercheurs en sécurité et les développeurs s’emploient à retracer les traces laissées par les commits Git de Jia Tan, leur origine, leur fuseau horaire et toute autre information accessible, afin de reconstituer le puzzle.

Comment les SBOM peuvent contribuer à atténuer CVE-2024-3094

• Une nomenclature logicielle (SBOM) offre une visibilité sur les composants logiciels et leurs versions, y compris dans les dépendances transitives.

• Les SBOM aident à suivre l’avancement des efforts de correction et à s’assurer que tous les projets affectés sont corrigés.

• Une fois à jour, les SBOM peuvent démontrer que les correctifs nécessaires ont bien été appliqués.

Que faire ensuite ?

• Suivez les recommandations de ce rapport de la Cybersecurity & Infrastructure Security Agency (CISA) concernant les mises à jour pour CVE-2024-3094

• Testez votre SBOM avec le SBOM Checker de Snyk

• Consultez cette mise à jour de Dark Reading