XZ Utils : comment une porte dérobée dans un composant de Linux a fait craindre le pire
panicattack.gif
Une faille de sécurité critique dans la suite d’outils XZ a déclenché une vague de peur et de recherche pendant le week-end. Elle témoigne d’une activité malveillante intense et d’une planification exemplaire. Sa découverte, presque par hasard, entraine une vaste réflexion sur les processus de validation.
Le 02 avril à 16h26
8 min
Logiciel
Logiciel
Un coup de chance. C’est ainsi que la découverte de la faille est qualifiée depuis vendredi. La vulnérabilité réside dans XZ Utils, une suite d’outils largement utilisée pour effectuer de la compression sans perte et incluant notamment les programmes lzma et xz, ainsi que quelques bibliothèques.
Le composant est présent dans toutes les distributions Linux qui, elles-mêmes, sont à la base d’un très grand nombre de serveurs. Les conséquences potentielles étaient gigantesques, d’autant que cette brèche n’était pas le résultat d’une erreur de programmation. Ce n’était pas un classique dépassement de mémoire tampon ou un bug de corruption mémoire. C’était le résultat d’une activité malveillante ayant pris place sur plus de deux ans.
Une découverte accidentelle
Andres Freund est un ingénieur travaillant comme développeur chez Microsoft, dont la spécialité est PostGreSQL. À la suite de plusieurs semaines de tests divers, en particulier de micro-benchmarks, il remarque plusieurs comportements troublants sur une connexion sécurisée SSH : elle nécessite 500 ms de plus pour s’établir et des pics d’utilisation CPU apparaissent.
Curieux, il se penche sur la question et remarque vite que ces changements se manifestent depuis des mises à jour récentes. Il tombe rapidement sur la dernière version déployée de XZ Utils et découvre le pot-aux-roses : il existe une porte dérobée pour OpenSSH.
L’ingénieur a publié sa découverte sur le forum Openwall ainsi que sur Mastodon le 29 mars, pour que l’information soit relayée.
Les versions 5.6.0 et 5.6.1 du paquet sont concernées. Sur les dernières 48 heures, nombre de mises à jour ont été déployées dans les distributions pour revenir à l’ancienne mouture 5.4.6. De nombreux éditeurs, comme Red Hat, ont publié des bulletins de sécurité pendant le week-end. La faille a été identifiée comme CVE-2024-3094, avec la note maximale de sévérité : 10.
Toutefois, ce sont essentiellement des versions de test et des systèmes en rolling release qui ont été touchés. La plupart des distributions « classiques » étaient encore sur des versions plus anciennes, notamment Debian et Ubuntu dans leurs révisions stables.
Vous pouvez connaître votre version de XZ Utils à tout moment via la commande suivante dans un terminal :
xz --version
Le fonctionnement de la porte dérobée
Extrêmement bien conçue et cachée, la backdoor ne réside pas dans le code source de XZ Utils, mais dans le processus de packaging des nouvelles versions, via notamment des fichiers de test. Il existe même des instructions pour masquer un peu plus la présence de la porte dérobée quand un outil de débogage est détecté.
Plus précisément, cette dernière consiste en une succession d’étapes, dont les dernières ne se déclenchent que si la bibliothèque principale de XZ Utils est compilée pour amd64 vers un paquet Debian ou RPM. Le processus culmine avec la création d’un fichier tarball. Il ne reste alors qu’à convaincre les équipes chargées des différentes distributions de répercuter la mise à jour.
La complexité de la porte dérobée est confirmée entre autres par la société Akamai, qui relève plusieurs techniques d’obfuscation. Le développeur Thomas Roccia, chercheur chez Microsoft, a publié une infographie pour résumer le fonctionnement de la backdoor, dans lequel on s’aperçoit vite du degré de complexité, qui témoigne à lui seul du soin apporté à cette attaque.
Car ses composants n’ont pas été ajoutés d’une traite avant la compilation des dernières versions de XZ Utils. Ils ont été intégrés petit à petit, au fil des mois. C’est un cas d’école de la compromission progressive d’une chaine d’approvisionnement, peut-être la mieux préparée jamais observée, selon l'ingénieur en cryptographie Philippo Valsorda.
Avalanche de questions
Comment cela a-t-il pu se produire ? Qui est à l’origine de cette porte dérobée ? Dans quel but ?
C’est une véritable enquête qui s’est ouverte dans le sillage de la découverte d’Andres Freund. De nombreux éléments troublants ont été collectés depuis. Mais avant de plonger dans les détails, il faut préciser certains points concernant XZ Utils lui-même.
Il s’agissait initialement d’un petit projet de loisir, créé et entretenu sur temps libre par Lasse Collin, dans le cadre du développement de la distribution finlandaise Tukaani (dérivée de Slackware). Mais ce petit projet est devenu une brique essentielle des distributions Linux et, de là, de l’infrastructure mondiale d’Internet.
En juin 2022, un changement crucial intervient : Lasse Collin annonce qu’à cause de « problèmes durables de santé mentale », il ne peut plus s’occuper du projet. Il cherche une personne pour le reprendre et en assurer la maintenance. La situation pourrait être à nouveau illustrée par le fameux dessin de xkcd.
Rapidement, une personne apparaît : Jia Tan, que l’on suppose être un homme. Il n’a pas d’historique de développements sur d’autres projets, mais propose rapidement plusieurs modifications. Jugées pertinentes et sans danger par Lasse Collin, elles sont intégrées.
La situation évolue très vite, puisque le 7 janvier 2023, Jia Tan merge lui-même son code dans le dépôt GitHub (fermé par Microsoft pendant le week-end), sans plus aucune vérification tierce. Le changement à la tête du projet devient « officiel » le 20 mars suivant, quand il remplace l’adresse email de Lasse Collin par la sienne comme moyen de contact.
Qui est Jia Tan ?
Personne ne sait actuellement qui est Jia Tan. Comme on peut le voir sur le fil créé par [email protected] sur Mastodon, cette question fait l’objet de nombreuses spéculations.
Comme indiqué, cette personne n’a pas d’historique de développement sur d’autres projets, et le nom ne fait ressortir aucune information probante. Il pourrait s’agir d’une véritable personne, d’une identité fabriquée de toute pièce, ou même de quelqu’un dont le compte a été piraté. Dans les archives du projet, certains ont retrouvé un nom plus complet, Jia Cheong Tan, sans que cela mène plus loin.
Selon d’autres, le nom choisi est un leurre pour laisser penser que l’auteur est asiatique. En fonction des heures de travail relevées et de la correspondance d’autres éléments comme les jours fériés, il semblerait plutôt que le développeur réside dans un pays d’Europe de l’Est.
La finalité de la porte dérobée
En quoi la porte dérobée est-elle dangereuse ? Son potentiel était immense. Elle aurait permis à toute personne possédant la bonne clé de nombreuses actions partout où était présent OpenSSH, de l’espionnage de ce qui transitait par la connexion à l’installation de code arbitraire, donc de charges virales, de logiciels espions et ainsi de suite.
Andres Freund, qui a découvert la porte dérobée, résume ainsi la situation : « Nous avons été incroyablement chanceux sur ce coup-là, et on ne peut pas compter là-dessus pour la suite ». En clair, il ne faut pas attendre qu’un tel coup de chance se répète à l’avenir. Car sa trouvaille, qu’il décrit comme accidentelle, s’est faite au dernier moment : son signal d’alarme a permis l’intervention des équipes de sécurité et le retrait des deux dernières versions alors qu’elles commençaient tout juste à être distribuée.
On trouve de nombreux commentaires dans les médias et discussions sur le sujet allant tous dans le même sens : internet est passé à côté d’une catastrophe. Et le constat amène systématiquement la question suivante : comment en est-on arrivés là, alors qu’il s’agit d’un développement open source d’une brique aujourd’hui essentielle ?
Parce que les moyens mis en œuvre relèvent d’un plan minutieusement préparé et d’une action progressive sur plus de deux ans. Un développeur originel fatigué, l’arrivée d’un repreneur providentiel, des preuves de ses compétences et de sa fiabilité et finalement l’implantation d’une porte dérobée non plus dans le code source du projet, mais dans la création des paquets à destination des distributions.
Aujourd’hui, le sentiment général qui se dégage des analyses est que Jia Tan n’existe pas et qu’il s’agit du travail d’un groupe soutenu par un État.
XZ Utils : comment une porte dérobée dans un composant de Linux a fait craindre le pire
-
Une découverte accidentelle
-
Le fonctionnement de la porte dérobée
-
Avalanche de questions
-
Qui est Jia Tan ?
-
La finalité de la porte dérobée
Commentaires (51)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 02/04/2024 à 16h42
La prochaine étape, c'est un projet libre intégrant dès le début une backdoor ?
Le 02/04/2024 à 17h40
Le 02/04/2024 à 17h59
L’intérêt d’avoir le code source a permis d’enquêter rapidement pendant un week-end où beaucoup de gens dans le monde ne travaillaient pas.
Libarchive aussi impacté en partie a été integré à windows 11 récemment. Donc logiciel fermé ne veut pas dire sans code libre.
Sans compter les dev qui repompent du code sans vérification sur stackoverflow (et maintenant chatgpt & co), code qui peut très bien intégrer ce genre de saleté.
Modifié le 02/04/2024 à 23h00
Nombre d'ERP du marché sont des passoires au socle technique obsolète reposant sur des libs open source pas spécialement à jour. Avec derrière un support que tu payes un fortune et qui est au mieux inutile. Ou alors ayant des interfaces de communication à la ramasse en matière de sécurisation. Ce qui leur "sauve" la mise c'est le fait qu'ils sont souvent prévus pour une installation on-premise donc en imaginant que la sécurité par les firewall c'est suffisant.
Le plus drôle, c'est quand ces vieux monolithes se "cloudifient" sans reconstruire leur produit en ce sens.
Le 04/04/2024 à 20h08
Log4j 1 encore il n'y a pas longtemps, des failles découvertes fréquemment, et le cloud poussé à l'extrême...
Le 03/04/2024 à 08h19
Le 02/04/2024 à 17h44
Ce qu'il faut en retenir, je pense, c'est que le monde du libre reste extrêmement fragile et peu soutenu. Hélas, les déconvenues s'enchaînent, et pas grand chose ne change. Les devs libristes et/ou open source restent vus et traités comme de bons petits travailleurs corvéable à souhait, et gratos. Et les gens trouvent ça normal, pourvu que ça leur permet des économies de bout de chandelle.
On va aussi voir les premières critiques contre son dev originel. Mais voilà, comme j'aime à le rappeler : folks who contribute nothing don't get a seat at the table. Faut pas critiquer si on ne fait rien.
Le 03/04/2024 à 08h18
Perso, je suis pour le libre, et c'est pour ça que la perte de confiance dans le libre que cette affaire peut provoquer me désole. 😔
Le 02/04/2024 à 18h13
Plusieurs années pour les découvrir - donc pas vraiment mieux que sur du proprio.
Le 04/04/2024 à 11h22
Le 04/04/2024 à 19h00
Mais des failles exploitables pendant plusieurs années en bidouillant un mail ou via la ligne de commande, c'est très louche.
Le 02/04/2024 à 19h33
Le 02/04/2024 à 16h44
Un gros scan de toute l'infra a été fait, on n'est pas touché, c'est le principal
Mais il existe du coup peut-être des portes dérobées dans d'autres paquets qui elles, n 'ont pas eu la chance d'être trouvées...
Il faut effectivement revoir le processus de validation, surtout sur un paquet présent sur absolument toutes les distributions Linux....
Le 02/04/2024 à 16h50
Le 02/04/2024 à 16h53
Le 02/04/2024 à 16h59
Le 02/04/2024 à 18h02
Kernel linux = des milliards de périphériques à risque (serveurs linux, android, azure & co…)
Le 03/04/2024 à 08h57
Quasiment tous ce qui permet le contrôle à distance par un technicien utilise OpenSSH aussi bien sous Linux, BSD, Mac et même possiblement Windows depuis quelques années. C'est à dire que presque tout serveurs et même une bonne partie des machines connectées auraient pu être compromis.
Le 03/04/2024 à 09h05
Le 04/04/2024 à 11h23
Modifié le 04/04/2024 à 20h41
Fedora RawHide est le précurseur des Alphas Fedora.
Donc oui tu as raison mais lorsqu'on utilise ce genre de distrib on doit mesurer les risques.
Et c'est bien pour ça qu'elles existent aussi!
Le 02/04/2024 à 18h12
Le 02/04/2024 à 23h17
Le 02/04/2024 à 16h52
xz –version
contrairement à ce qu'indique l'article, si vous avez la version infectée, vous allez probablement installer la backdoor sur votre machine. Passez par votre gestionnaire de paquet.Le 02/04/2024 à 17h49
Le 02/04/2024 à 18h04
Toujours est-il qu'inviter à lancer un exécutable potentiellement infecté, c'est plus que moyen.
Le 02/04/2024 à 18h23
xz --version
n'appelle aucune partie du code contaminé.Modifié le 02/04/2024 à 21h00
Mais effectivement, le principe à l'origine était de ne pas lancer la commande même avec un débogueur.
Par contre, ne pas lancer xz, c'est compliqué vu que c'est pas mal utilisé par les logiciels (soit via la lib, soit via l’exécutable) sur ma distro, j'ai une vingtaine de dépendances pour xz dont bind, grub, systemd, libxml2…)
Le 02/04/2024 à 19h34
Le 02/04/2024 à 17h42
Le 02/04/2024 à 17h50
Modifié le 02/04/2024 à 18h57
2024-04-01 12:22:29 status installed xz-utils:amd64 5.6.1+really5.4.5-1
Le 02/04/2024 à 20h08
Et ça se comprend : cela permet d'éviter de devoir downgrader des paquets qui auraient comme dépendance une des versions infectées.
Le 02/04/2024 à 19h53
Modifié le 02/04/2024 à 18h40
A une lettre près et le développeur se serait attaqué à Nicky Larson.
Sinon le hasard fait quelque fois bien les choses et la curiosité à du bon :)
Le 02/04/2024 à 18h55
Le 02/04/2024 à 21h10
Je ne sais pas trop comment se passent les audits de sécurité de code, mais je ne suis pas sûr que la partie "tests" soit analysée aussi scrupuleusement que la partie du code principal.
Le 02/04/2024 à 23h24
Le 04/04/2024 à 11h51
Le 03/04/2024 à 01h01
Le 03/04/2024 à 08h23
Le 06/04/2024 à 09h46
Cela va inciter à mieux analyser les paquetages eux-mêmes : tout paquetage dont l'exécution conduit à modifier le code source doit être considéré comme suspect.
Modifié le 03/04/2024 à 09h45
Le 03/04/2024 à 10h57
D'ailleurs, il n'est pas resté les bras croisé: il a corrigé une erreur introduite volontairement par Jia Tan ("CMake: Fix sabotaged Landlock sandbox check") directement dans le build de xz (pas ds les packages debian). Cf le post de fofo9012 ci-dessous.
Et oui, de grosse boites comme M$ devraient contribuer à ce genre de projet vitaux (ou bien les forker/ré-écrire). Mais j'ai donc peu d'espoir...
Le 03/04/2024 à 14h50
Le 03/04/2024 à 12h18
Cybersécurité et open source : l’électrochoc Heartbleed « n’a pas changé grand chose »
Le 03/04/2024 à 18h26
Là, on voit bien qu'il faut une approche différente. Les attaquants ont certainement cherché des cibles du style "la petite lib d'xkcd", ie. le petit truc utilisé massivement (dont par certains packaging de sshd, cœur du problème ici) mais maintenu par un hobbyiste plus ou moins démotivé. C'est exactement ce genre de shortlist que l'industrie doit aussi faire de son côté: identifier toutes ces libs peu maintenues mais très utilisées. Et peut-être redonner vie à la CII...
Modifié le 03/04/2024 à 09h39
XZ Utils Release Notes
======================
+5.6.1 (2024-03-09)
[...]
+ * Minor improvements to tests.
Modifié le 03/04/2024 à 23h48
GitHub
https://tukaani.org/xz-backdoor/
c'est assez impressionnant que personne n'ait encore complètement compris les impacts.
Ma
compréhensionlecture : toute distrib à base (indirecte) de debian (dont ubuntu et dérivéssssss...) ou redhat (et dérivésssss... dont centos qu'on trouve partout dans tout cloud) aurait exécuté sans broncher une "charge" reçue depuis un port SSH ouvert. Ensuite c'est openbar : exécution de tout et n'importe quoi !!!Ce qui fait peur c'est que xz, c'est le "zip du libre" (gz > bzip2 > lzma > xz), y'en a partout : le noyau linux ou android c'est +/- par défaut, dans Windows WHSL... donc techniquement n'importe quel truc utilisant XZ et accessible de l'extérieur pourrait exécuter une charge !
Le 05/04/2024 à 22h21
Avec ce niveau de sophistication, on peut maintenant se demander si sa "fatigue" est arrivée par hasard.
Il a pourrait tout aussi bien être victime d'une attaque par le vecteur social ou autre, afin de permettre l'introduction du "contributeur" "jia tan" comme personne de confiance aux yeux de la communauté.
Modifié le 05/04/2024 à 22h57
https://tukaani.org/xz-backdoor/