Connexion
Abonnez-vous

XZ Utils : comment une porte dérobée dans un composant de Linux a fait craindre le pire

panicattack.gif

XZ Utils : comment une porte dérobée dans un composant de Linux a fait craindre le pire

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

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.

Commentaires (51)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Bonjour la psychose et la perte de confiance dans l'open-source/libre...
La prochaine étape, c'est un projet libre intégrant dès le début une backdoor ?
votre avatar
Parce que c'est plus rassurant un logiciel fermé ? Cette porte dérobée, même découverte par hasard, permet justement de prouver la confiance qu'on peut avoir dans les logiciels libres.
votre avatar
Il y a déjà eu des backdoor sur des produits privateurs et il y en aura encore. des salariés (ou des sous-traitants) payés par un tiers pour ce genre d’actions est possible.

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é.
votre avatar
C'est même encore pire dans un logiciel aux sources fermées.

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.
votre avatar
C'est amusant, j'ai l'impression que tu parles aussi de Jira :mrgreen:
Log4j 1 encore il n'y a pas longtemps, des failles découvertes fréquemment, et le cloud poussé à l'extrême...
votre avatar
Pour certains, les logiciels fermés sont plus rassurants parce que tu mets ta confiance dans un éditeur et non dans une personne.
votre avatar
Je ne vois pas en quoi il en résulterait une perte de confiance dans l'opensource. C'est justement sa composante ouverte qui a permis de confirmer la faille. Alors que sur du closed-source, le problème serait peut-être resté discret incroyablement longtemps.
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.
votre avatar
Il y a toujours des gens pour trouver des arguments contre le libre. En l'occurrence, dans ce cas précis, un argument serait de dire que dans les logiciels fermés, comme ils sont fournis par un éditeur, tout est question de confiance dans l'éditeur, alors qu'ici c'est dans une "personne" que tu mets ta confiance.

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. 😔
votre avatar
Trop tard, et depuis des années... BSD a eu sa backdoor via le serveur mail, Linux via sudo...

Plusieurs années pour les découvrir - donc pas vraiment mieux que sur du proprio.
votre avatar
Référence ? Une porte dérobée, c'est quand c'est mis volontairement et je ne me souviens pas d'un cas documenté pour sudo.
votre avatar
Effectivement, dans les cas de sudo et bsd, ce ne sont que des présomptions...
Mais des failles exploitables pendant plusieurs années en bidouillant un mail ou via la ligne de commande, c'est très louche.
votre avatar
Il faut déjà avoir la version spécifique contaminée, ce qui est loin d'être évident.
votre avatar
Je suis tombé sur ça ce matin... Flippant que la découverte soit le fruit d'un pur hasard...

Un gros scan de toute l'infra a été fait, on n'est pas touché, c'est le principal :D

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....
votre avatar
À moins d'installer des alphas partout il est improbable d'être touché par cette vulnérabilité....
votre avatar
On préférait être sûr vu la tronche du CVE :p
votre avatar
ba si la backdoor n'avaient pas été découverte, dans quelques temps elle aurait été présente dans toutes les distro y compris celle qui ne sont pas en rolling. donc le potentiel est énorme.
votre avatar
Il (ou ils ?) ont demandé l’inclusion dans le kernel linux…

Kernel linux = des milliards de périphériques à risque (serveurs linux, android, azure & co…)
votre avatar
Pas besoin que ça soit dans le kernel Linux. Une backdoor dans OpenSSH touche déjà bien plus de machine intéressantes pour les pirates.
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.
votre avatar
En l'occurrence l'attaque réduisait intentionnellement la portée aux .deb et .rpm, certainement pour éviter aux hackers d'avoir à "gérer" trop de familles *nix. Il faut voir que si pour une raison x ou y le build génère des problèmes non anticipés (par exemple car non testé sur un système donné par le hacker) ça risque de mettre tout son travail de sape à l'eau.
votre avatar
Si on utilise des "rolling releases" (Arch Linux, Debian sid, Fedora rawhide), on a été touché.
votre avatar
Debian SID est considéré comme une Alpha.

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!
votre avatar
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...
C'est ce que j'appelle, pour marquer les esprits, le « principe des bébés congelés » : dans la mesure où l'on fouille rarement dans les congélateurs de tierces personnes, pour chaque affaire de bébé congelé trouvé, il faut se dire qu'il y en a cent ou mille qui ne seront jamais trouvés.
votre avatar
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 voir qu'une backdoor exploitée est aussi plus visible car l'exploitation laisse des traces, lève des alarmes etc. ce qui braque tout de suite les regards vers les composants susceptibles d'être compromis. Donc oui il y a certainement d'autres backdoors actives, mais a priori elles finissent par être repérées (à moins d'être dormantes / non exploitées), c'est une traque sans fin.
votre avatar
Ne lancez surtout pas la commande 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.
votre avatar
Ça ne marche pas du tout comme ça. Le code concerné est une bibliothèque (la liblzma), appelée dans plein de contextes différents. La backdoor est installée dès que la lib est installée ; il n'y a pas besoin d'autre action de l'utilisateur. Et même pire : la backdoor n'est effective que dans un daemon (en particulier sshd) et ne s'active pas dans les outils lancés en interactif. Bref, tu n'as visiblement pas compris son fonctionnement.
votre avatar
Effectivement, j'ai lu en diagonal et réagi à chaud.

Toujours est-il qu'inviter à lancer un exécutable potentiellement infecté, c'est plus que moyen.
votre avatar
Non, lancer xz --version n'appelle aucune partie du code contaminé.
votre avatar
Ça, on le sait depuis que la backdoor a été analysée par des expert⋅e⋅s (merci à ces personnes !)

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…)
votre avatar
C'est d'ailleurs de là que vient la faille : sshd n'a pas de dépendance directe sur liblzma, mais seulement sur systemd, qui lui dépend de liblzma.
votre avatar
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.
C'est clairement un coup de Microsoft ! Ça cible l'image de Linux, le gars qui a trouvé ça est "uningénieur travaillant comme développeur chez Microsoft". L'injection de la backdoor s'est faite sur Github, rachetée par... Microsoft il y a quelques années. Le coup était prévu depuis 2018, pas seulement 2 ans.
votre avatar
Si ça n'avait pas été intercepté à temps, la backdoor aurait aussi fini par être présente dans WSL.
votre avatar
Sur WSL, on est passé sur... 5.6.1 ! Mais pas de panique, il s'agit d'une version spéciale. En réalité, il s'agit de la version 5.4.5-1. Ouf...

2024-04-01 12:22:29 status installed xz-utils:amd64 5.6.1+really5.4.5-1
votre avatar
Ce n'est pas propre à WSL. C'est le choix d'Ubuntu.

Et ça se comprend : cela permet d'éviter de devoir downgrader des paquets qui auraient comme dépendance une des versions infectées.
votre avatar
J'ai du mal à voir si ce commentaire est ironique ou non.
votre avatar
XZ Utils ...

A une lettre près et le développeur se serait attaqué à Nicky Larson. :transpi:
Sinon le hasard fait quelque fois bien les choses et la curiosité à du bon :)
votre avatar
il semblerait plutôt que le développeur réside dans un pays d’Europe de l’Est.
C'est donc un Chinois du FSB ! :D
votre avatar
Je ne sais pas si cela a déjà été fait dans le passé, mais personnellement je trouve cela vraiment malin d'avoir caché le code malicieux dans les fichiers de tests et de le lire au moment de la compilation.
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.
votre avatar
d'autant que ce n'est pas le code de test qui est incriminé, mais les fichiers data, donc encore moins le genre de truc qu'on va auditer scrupuleusement (du moins jusqu'à aujourd'hui)
votre avatar
c'est précisément ce que je me suis dit en lisant l'article : la plupart des outils d'analyse de vulnérabilités se basent sur le code source, parfois sur le comportement du package. Mais l'attaque d'un module par la bande (parce-que là c'est OpenSSH qui est visé), je ne vois pas comment ça serait possible de la repérer, même par des outils de SCA...
votre avatar
N'empêche, les mecs doivent être sacrément verts de voir au moins 2 ans de boulot minutieux partir en fumée au moment où ça allait commencer à devenir intéressant 🤭.
votre avatar
Un loupé mais combien de réussites ?
votre avatar
Oui, clairement. Et on a bien senti sa fébrilité à enfin arriver à son but, lui qui a envoyé des courriels exprès pour demander que la nouvelle version vérolée soit intégrée au plus vite à toutes les distributions. Il s'est fait rattraper par la patrouille avant, mais sur ce coup on l'a échappé belle.
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.
votre avatar
Je trouve quand même qu'il devrait y avoir une forme de soutient ou des personnes de chez Github et d'autres grosses entreprises qui devraient chercher à aider Lasse Collin pour son taff. Le gars à build un projet qui a une ampleur monumentale dans le cadre d'un "hobby" le tout bénévolement mais ça ça n'a pas l'air de toucher grand monde. Ça devrait lancer le débat sur l'aide que les grosses entreprises comme microsoft qui bénéficie financièrement de ce genre de projet devrait fournir aux petit développeur qui ont de vrais problèmes, plutôt que de parler de "perte de confiance dans l'opensource" qui n'est absolument pas pertinent dans ce cas.
votre avatar
Heureusement, ca touche des gens, et certains qui sont en contact avec lui ont récemment publié de ses nouvelles (spoil: il va bien).

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...
votre avatar
J'avais les infos sur sa situation vu que j'ai check le post mastodon et on ne sait pas si la raison pour laquelle il avait des problèmes de santé mentale était à cause du projet mais je pense qu'avec un peu de reconnaissance financière des big corps ça aurait peut être pu l'aider un peu à tenir le coup
votre avatar
votre avatar
Après Heartbleed l'industrie avait lancé la CII pour financer des projets open-source, mais ils se sont focalisé sur les projets directement liés à la sécurité (Heartbleed / openssl ayant focalisé l'attention).

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...
votre avatar
Le github a été fermé mais, le git d'origine est toujours dispo : https://git.tukaani.org/?p=xz.git;a=shortlog;h=refs/heads/master, y'a même le changelog : :)



XZ Utils Release Notes
======================
+5.6.1 (2024-03-09)
[...]
+ * Minor improvements to tests.
votre avatar
la complexité du truc est folle :
gist.github.com GitHub
https://tukaani.org/xz-backdoor/

c'est assez impressionnant que personne n'ait encore complètement compris les impacts.

Ma compréhension lecture : 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 ! :eeek2:
votre avatar
Qu'est devenu le "développeur originel fatigué" ?

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é.
votre avatar
Il a mis à jour cette semaine sa page sur xz, avec quelques 1ers détails :

https://tukaani.org/xz-backdoor/

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

Fermer