ClickCease Une plongée en profondeur dans le compromis xz

Table des matières

Rejoignez notre populaire bulletin d'information

Rejoignez 4 500+ professionnels de Linux et de l'Open Source !

2 fois par mois. Pas de spam.

Une plongée en profondeur dans le compromis xz

Joao Correia

2 avril 2024 - Évangéliste technique

xz est un paquetage largement distribué qui fournit une compression sans perte pour les utilisateurs et les développeurs, et qui est inclus par défaut dans la plupart, sinon la totalité, des distributions Linux. Créé en 2009, il a depuis publié de nombreuses versions.

En tant que projet open-source, il est disponible sur GitHub. Cependant, au moment de la rédaction de cet article, il n'est pas possible de visiter la page du projet vous accueille avec un message indiquant que "ce dépôt a été désactivé en raison d'une violation des conditions de service" au lieu de la page traditionnelle de GitHub. Cette violation est due à la distribution de logiciels malveillants. Dans cet article, nous examinons le quoi, le pourquoi, le comment et peut-être même le "qui" derrière cet incident.

Lorsque l'affaire a éclaté à la fin de la semaine précédant Pâques, la sphère de la cybersécurité sur Twitter a explosé, les internautes étant obsédés par les moindres détails. Cet article s'appuie largement sur les informations recueillies et publiées dans le cadre de ces enquêtes, dont une grande partie est consolidée iciCet article s'inspire largement des informations recueillies et publiées dans le cadre de ces enquêtes, dont une grande partie est consolidée ici, ainsi que des informations glanées par l'auteur au cours de ses propres recherches. Dans la mesure du possible, l'auteur renvoie aux sources d'origine, et si aucune source directe n'est mentionnée, le lecteur peut supposer que l'information provient de la base de données GitHub gist récapitulant l'événement ou de cette chronologie.

N'oubliez pas que cette histoire est très récente. Certains aspects n'ont pas encore été résolus et certains indices laissent entrevoir la possibilité (peu probable) que la personne que l'on croyait à l'origine de l'incident ne le soit pas nécessairement. Ce point est abordé plus en détail dans la section "Mise en garde" de cet article.

Attachez vos ceintures, le trou de lapin est profond dans ce cas.

 

Contexte historique

 

Le projet xz, comme beaucoup d'autres projets open-source, a été créé comme le projet d'un seul développeur qui a eu une idée et l'a partagée avec le monde. En 2009, Lasse Collins, auparavant responsable de la maintenance de lzma-utils, un autre projet lié à la compression, a créé xz. Il a été conçu comme une extension, ou une évolution, de lzma, à tel point que liblzma est désormais livré par défaut avec le paquet xz.

Comme c'est souvent le cas dans les projets menés par une seule personne, l'auteur était responsable de la majeure partie du code et de la gestion des modifications occasionnelles apportées par des tiers, de l'intégration du code dans le référentiel et de la publication des nouvelles versions. Au fur et à mesure que le projet prenait de l'ampleur, la charge de la gestion devenait plus lourde et, finalement, d'autres contributeurs ont été reconnus pour leurs efforts et ont reçu des autorisations pour gérer des tâches telles que la révision du code, l'acceptation ou le rejet des soumissions et la gestion du référentiel.

Il y a un peu plus de deux ans, Jia Tan, un développeur qui avait déjà contribué au projet, s'est vu accorder des permissions de validation et de gestion des versions. Rétrospectivement, le processus d'ajout d'un nouveau responsable semble avoir fait partie d'une campagne d'ingénierie sociale visant Lasse Collins. La chronologie de ces échanges de courriels peut être consultée ici.

Sous la pression et les accusations d'abandon du projet ou de perte d'intérêt, plusieurs utilisateurs différents (ou peut-être une seule personne derrière plusieurs noms d'utilisateur) ont envoyé des messages à la liste de diffusion du projet. Ils se sont plaints de retards dans l'acceptation des correctifs, dans la publication de nouvelles versions et dans l'adoption de différentes méthodes, jusqu'à ce que le responsable du projet commence à s'appuyer sur un nouveau contributeur enthousiaste. Les comptes de messagerie à l'origine de ces moyens de pression semblent n'avoir aucune présence sur l'internet en dehors de cette liste de diffusion.

Dire que xz est largement utilisé est un euphémisme. xz est l'un des formats de compression que vous pouvez utiliser pour empaqueter le noyau Linux sur un système, ce qui le rend indispensable pour démarrer ce système. Les taux de compression atteints et la vitesse de décompression en font une option parfaite pour les versions peu encombrantes, les images du noyau et d'autres composants.

 

Le temps manquant

 

Par une ironie du sort, un ingénieur logiciel de Microsoft, Andres Freund, effectuait des mesures de temps sur des machines virtuelles Linux afin d'établir une base de référence pour une tâche sans rapport avec la sienne. Il a commencé à remarquer du "bruit" dans les relevés. Le processus sshd, chargé d'accepter les connexions shell sécurisées à distance, utilisait une quantité excessive de CPU, même lors des tentatives de connexion échouées, avec un délai de 500 ms ayant un impact sur les connexions. Ce délai inexpliqué a incité M. Freund à approfondir ses recherches, en utilisant des outils de surveillance des performances (perf) et de débogage (dbg) pour identifier le problème.

Il a a découvert une porte dérobée dans xz. Plus précisément, il a identifié la porte dérobée et le code injecté, car la porte dérobée fonctionne en s'appuyant sur certaines fonctions appelées par sshd. Il est important de noter, et les lecteurs attentifs le savent peut-être déjà, que sshd ne dépend pas de xz ou de liblzma. Cependant, dans les systèmes qui utilisent systemd pour charger sshd, systemd inclut liblzma comme dépendance. Cette connexion a permis d'introduire le code de la porte dérobée dans sshd. Les systèmes qui entrent dans cette catégorie sont Fedora, Ubuntu, Debian et la plupart de leurs distributions dérivées.

 

La porte dérobée

 

La méthode par laquelle le code a été introduit dans xz (et liblzma) a consisté à ajouter quelques fichiers binaires au dépôt xz et à compromettre le processus de construction. Ces fichiers, initialement soumis par Jia Tan dans le cadre d'une "suite de tests" pour xzétaient des blobs binaires "créés à la main avec un éditeur hexadécimal". La lecture d'un code source est déjà une tâche complexe, mais celle d'un code binaire est presque impossible. Il existe un commentaire ironique selon lequel "il n'y a pas de meilleur code source que les fichiers eux-mêmes". En effet.

Le commit incluant les fichiers malveillants a été effectué le 23 février 2024. Pour autant que l'on sache actuellement, le code malveillant n'est présent que dans deux des fichiers binaires, les autres semblant remplir les fonctions prévues - tester différentes conditions d'échec dans le processus de compression ou de décompression de xz et de liblzma.

L'un des aspects notables de la porte dérobée est que si un utilisateur aléatoire extrait le code du dépôt xz et le compile après l'inclusion de la porte dérobée, il ne se retrouvera pas avec un binaire compromis (pour autant qu'on le suppose actuellement, bien que cela puisse être prouvé faux plus tard). Le code d'injection réel ne serait inclus dans la sortie que si un fichier spécifique "build-to-host.m4" était présent lors de la compilation, mais ce fichier a également été ajouté à ".gitignore", ce qui le rend inaccessible aux opérations git normales généralement utilisées par les utilisateurs finaux. Cependant, il est utilisé pendant le processus de construction d'un paquetage d'une distribution Linux.

Cette approche visait à intégrer le code dans les distributions Linux actuelles, tout en rendant plus difficile la reproduction de l'incident par les chercheurs en sécurité dans un environnement contrôlé.

Le 24 février, un jour après avoir ajouté les fichiers malveillants, le même utilisateur a étiqueté (c'est-à-dire présenté comme la prochaine version) xz-5.6.0. Les distributions Linux récupèrent généralement les nouvelles versions des paquets et, par exemple, Debian l'a incluse dans le dépôt instable quelques jours plus tard.

Le 28, un correctif supplémentaire a été ajouté par Jia Tan qui interférait avec la détection de landlock pendant le processus de construction. Landlock est une fonctionnalité de sécurité qui empêche (entre autres) l'établissement de liens et l'importation de code, qui serait déclenchée si elle était activée lors de la compilation.

Cela a été réalisé d'une manière très subtile. Un simple "." (point) ajouté à "CMakeLists.txt" a perturbé la compilation de la vérification du bac à sable, faisant en sorte que la détection du bac à sable renvoie toujours un faux, ce qui, à son tour, l'a toujours désactivé pour le code malveillant. Cette modification n'a pas été détectée lorsqu'elle a été soumise. De manière significative, Lasse Collins (et non Jia Tan) est crédité de ce commit, qui peut avoir été falsifié, ou le changement très subtil n'a pas été repéré avant d'ajouter le code.

Notamment, le 29 février, une sur le projet systemd demandait d'arrêter de lier liblzma afin de réduire la taille des images. Cela aurait permis de déjouer l'attaque. Cet événement ne semble pas lié à l'attaque proprement dite et est considéré comme une coïncidence susceptible d'avoir accéléré le calendrier. On ne sait pas si des conversations antérieures sur le sujet étaient publiques et connues de l'attaquant.

La fonction qui invoque le code malveillant est _get_cpuid. Il se peut que d'autres fonctions restent à découvrir. Cette fonction exécute le code de la charge utile malveillante avant d'effectuer le travail original de _get_cpuid et de le renvoyer, ce qui ajoute le temps de latence remarqué par l'ingénieur de Microsoft. Plus précisément, cette fonction est appelée au début du processus de validation du certificat lors de l'établissement d'une connexion.

Certaines distributions ont commencé à observer des erreurs valgrind dans cette fonction pendant l'analyse. Le 8 mars, Jia Tan a soumis du code pour répondre aux détections de Valgrindqui, avec le recul, semble simplement désactiver l'analyse du code malveillant.

Le lendemain, le 9 mars, Jia Tan a mis à jour les fichiers dissimulés, sous prétexte qu'"ils ont été créés avec un caractère aléatoire local à sa machine, et pour mieux les reproduire à l'avenir, une valeur de semence constante devrait être utilisée". Là encore, les fichiers binaires sont difficiles à analyser, surtout lorsque le code de la porte dérobée se contente de sélectionner des valeurs à partir d'emplacements prédéfinis dans le blob binaire, ce qui rend la détection pratiquement impossible. Le même jour, il a marqué et publié xz-5.6.1.

Le 25 mars, l'un des comptes de messagerie utilisés pour faire pression sur le responsable original de xz a refait surface, faisant maintenant pression sur le projet Debian pour qu'il inclue la nouvelle version de xz. faisant pression sur le projet Debian pour qu'il inclue la nouvelle version de xz. D'autres comptes apparemment fantômes se sont joints à eux pour augmenter la pression.

Le 28 mars, Jia Tan a déposé un rapport de bogue auprès de Ubuntu pour l'inclusion de xz-5.6.1puisque Debian l'avait déjà inclus.

Le comportement malveillant est vise spécifiquement les systèmes x86-64 utilisant la glibc (il dépend d'une fonction fournie par la glibc) et exécutant sshd via systemd. Cet ensemble de conditions correspond aux distributions basées sur Debian et Red-Hat.

La désobfuscation et l'analyse du code malveillant ont révélé qu'il s'activait chaque fois qu'une connexion entrante était reçue sur sshd. Ce n'est que récemment que l'on a découvert que le code attend une clé publique particulière lors de la réception d'une connexion. Si cette clé n'est pas présente, sshd fonctionnera comme d'habitude. Cependant, lorsqu'une clé contrôlée par l'attaquant est présente, le code déclenche un comportement différent, contrôlé à distance.

 

Détection, et le monde de l'Open Source est ébranlé

 

Le 28 mars, l'enquête d'Andres Freund a permis d'identifier la porte dérobée. Les distributions ont été informées et des mises à jour ont été publiées qui ont essentiellement ramené les paquets à une version antérieure à l'implication de Jia Tan dans le projet xz. Cela signifie qu'il existe maintenant une version "5.6.1+vraiment5.4.5" de xz disponible dans les dépôts de plusieurs distributions.

Jusqu'à présent, les distributions qui ont reconnu la présence du paquet compromis incluent Fedora Rawhide, Fedora 40 beta, et Debian.

xz jouant un rôle crucial dans le processus de construction des paquets, le projet Debian a choisi de reconstruire l'ensemble de son système de construction, car il utilisait une version de xz qui incluait les correctifs de Jia Tan (avant l'inclusion supposée de la porte dérobée).

Une attaque contre la chaîne d'approvisionnement peut avoir une portée stupéfiante. Bien que cela soit souvent dit, cela ne devient vraiment évident qu'avec des preuves claires et sans équivoque, comme cette attaque. 

L'analyse de cette situation fait apparaître plusieurs problèmes :

Tout d'abord, la manière dont les projets open-source sont gérés, sans financement ni ressources adéquats, conduit à des situations où les responsables peuvent être débordés et amenés à accepter des compromis moins qu'idéaux. Cette vulnérabilité permet aux acteurs de la menace de s'infiltrer et, à terme, de prendre le contrôle de projets clés.

Deuxièmement, xz n'est que le projet qui s'est fait prendre. Sans le retard causé par le code malveillant, qui aurait probablement pu être optimisé avec plus de temps, cette attaque n'aurait peut-être pas été détectée du tout, et tout le monde aurait finalement exécuté une version compromise de xz sur leurs systèmes basés sur Debian et Red-Hat. En rétablissant xz, on suppose que cette menace particulière a été neutralisée. Cependant, la certitude de cette affirmation reste incertaine à l'heure actuelle.

Troisièmement, du code est ajouté aux projets open-source chaque minute de chaque jour, dans d'innombrables projets différents. La manière dont les dépendances sont utilisées et contrôlées permet à une cascade de fausses pistes d'atteindre la cible visée, même si aucun code malveillant ne touche jamais directement le paquet cible visé par l'attaquant.

Quatrièmement, l'argument selon lequel le code source ouvert est plus sûr simplement parce qu'il est ouvert est un homme de paille. Cet argument n'est valable que s'il y a suffisamment de personnes motivées pour examiner chaque ligne de code de chaque projet, à chaque validation. Cela nécessite un grand nombre de personnes hautement qualifiées, effectuant une quantité importante de travail non rémunéré, indéfiniment. La capacité de vérifier et de contrôler le code n'est efficace que si la vérification et le contrôle sont réellement effectués. Même dans ce cas, en raison de sa nature même et des méthodes disponibles pour l'obscurcissement, il est possible de glisser un code malveillant dans des projets qui ne se doutent de rien. En fait, on pourrait dire que, du point de vue de la sécurité, la disponibilité du code source pourrait également aider, et peut-être dans une large mesure, les acteurs malveillants qui cherchent à identifier les vulnérabilités, plus qu'elle n'aide les utilisateurs finaux. Si le code source ouvert offre de nombreux avantages indéniables, la sécurité intrinsèque n'en fait pas toujours partie. Cette porte dérobée a été découverte par hasardet non parce que quelqu'un examinait activement le code.

Cinquièmement, la construction d'une réputation dans la communauté open-source repose souvent uniquement sur l'historique des livraisons dans GitHub et rien d'autre. Démontrer de l'intérêt pour un projet et contribuer à quelques corrections de code est souvent suffisant pour être accepté. La démonstration d'une volonté d'aider peut être facilement fabriquée. Il est donc très difficile d'identifier des personnes spécifiques derrière des comptes essentiellement anonymes. Un utilisateur peut avoir plusieurs comptes ou en créer de faux lorsqu'un compte devient suspect ou est identifié comme malveillant. Une organisation disposant de ressources suffisantes peut créer et gérer une armée de ces comptes.

Sixièmement, il n'existe souvent pas de plan de reprise après sinistre clairement défini pour la plupart des projets open-source. Il est difficile de revenir à un bon état connu s'il est même difficile de déterminer quel est cet état connu. Bien qu'un compte soit accusé d'être à l'origine de cette attaque, il n'est pas certain qu'il ait été le seul utilisé.

 

L'éventuelle mise en garde

 

L'analyse du déroulement de cet incident semble indiquer l'implication d'un acteur ou d'un groupe de menace bien financé et hautement qualifié. Voici quelques observations qui méritent d'être soulignées :

 

  • Jia Tan semble suivre un horaire de travail de 9 à 5 (ou 6). Les activités Commit et GitHub suggèrent ce schémaLes week-ends et les jours fériés correspondant à certains pays sont évidents au premier coup d'œil. Cependant, il est important de noter que les horodatages dans les commits git peuvent être manipulés à volonté, et - comparé au niveau d'expertise démontré dans le code de la porte dérobée - la modification de l'heure d'un commit est triviale.
  • Jia Tan a contribué au code de plusieurs projets en dehors de xz. En fait, le compte a même soumis du code au programme OSS-Fuzzde Google, un outil conçu pour identifier les comportements malveillants ou bogués dans les projets open-source, ainsi que plusieurs autres projets liés à la compression. L'ensemble de ce code fait désormais l'objet d'un examen minutieux et n'est plus digne de confiance.
  • Curieusement, le fuseau horaire des modifications où les fichiers malveillants ont été téléchargés diffère du fuseau horaire typique associé au compte de Jia Tan. Une analyse détaillée de cette incohérence est disponible iciL'analyse détaillée de cette incohérence peut être consultée ici, mais elle soulève la possibilité que le compte du développeur ait été compromis au lieu d'être utilisé intentionnellement. Bien que cela reste une possibilité, d'autres aspects de l'incident la rendent moins plausible. Il s'agit néanmoins d'un point à prendre en considération.

 

Remarques finales

 

Cette histoire est probablement loin d'être terminée. Jusqu'à présent, la réponse a consisté à fermer le dépôt GitHub de xz, à ramener les paquets de distribution à une version plus ancienne et à réévaluer d'autres commentaires de l'utilisateur supposé responsable.

 

Les questions ouvertes sont les suivantes :

 

  • Il s'agit de l'une des attaques les plus sophistiquées de la chaîne d'approvisionnement à ce jour. Il est difficile de concevoir qu'elle soit l'œuvre d'un seul pirate. Qui est à l'origine de cette attaque ? Si Jia Tan respectait un horaire de travail, quel pays, quelle organisation ou quel groupe payait son salaire ?
  • Le maintien d'une opération pendant plus de deux ans nécessite des ressources et des efforts considérables. Quel était l'objectif final ? À terme, tous les systèmes basés sur Debian et Red Hat auraient été compromis. Qui a intérêt à avoir accès à tous les systèmes utilisant ces distributions ?
  • L'heure et les fuseaux horaires sont facilement manipulés dans les messages de validation. Ont-ils été réglés intentionnellement pour pointer vers des zones spécifiques ?
  • Tous les codes malveillants ont-ils été identifiés ? D'autres charges utiles doivent-elles encore être découvertes ?
  • Le processus sshd était-il le seul visé ?
  • Quels autres projets ont été touchés par l'attaque ?

 

Dans le domaine de la cybersécurité, nous sommes constamment en train d'esquiver les balles. Jusqu'à ce que nous ne le fassions plus. Et le plus curieux, c'est que nous ne verrons même pas celle qui nous atteint avant qu'il ne soit trop tard.

Voulez-vous en savoir plus sur les vulnérabilités et expositions communes (CVE) et comprendre l'importance des CVE dans la sécurité informatique ? Regardez notre LinuxTalk with Tuxcare Youtube Serie EP2

Résumé
Une plongée en profondeur dans le compromis xz
Nom de l'article
Une plongée en profondeur dans le compromis xz
Description
xz a été désactivé en raison d'une violation des conditions d'utilisation. Voyons ce qu'il en est, pourquoi, et même qui est à l'origine de cet incident.
Auteur
Nom de l'éditeur
TuxCare
Logo de l'éditeur

Vous cherchez à automatiser la correction des vulnérabilités sans redémarrage du noyau, temps d'arrêt du système ou fenêtres de maintenance programmées ?

Découvrez le Live Patching avec TuxCare

Devenez rédacteur invité de TuxCare

Commencer

Courrier

Rejoindre

4,500

Professionnels de Linux et de l'Open Source
!

S'abonner à
notre lettre d'information