Photo d'une pince coupante

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

panicattack.gif

Avatar de l'auteur
Vincent Hermann

Publié dans

LogicielSécurité

02/04/2024 8 minutes
51

Photo d'une pince coupante

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.

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

La suite est réservée à nos abonnés.

Déjà abonné ? Se connecter

Abonnez-vous

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

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

Commentaires (51)


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 ?
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.

Zetny

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.
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é.

Zetny

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.
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.
Modifié le 02/04/2024 à 23h00

Historique des modifications :

Posté le 02/04/2024 à 22h59


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.

Le plus drôle, c'est quand ces vieux monolithes se "cloudifient" sans reconstruire leur produit en ce sens.

SebGF

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.
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...

Zetny

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.
Pour certains, les logiciels fermés sont plus rassurants parce que tu mets ta confiance dans un éditeur et non dans une personne.
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.

grsbdl

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.
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. 😔
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.

Wosgien

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.
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.

Stéphane Bortzmeyer

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.
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.
Il faut déjà avoir la version spécifique contaminée, ce qui est loin d'être évident.
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....

À moins d'installer des alphas partout il est improbable d'être touché par cette vulnérabilité....

DikVin

À moins d'installer des alphas partout il est improbable d'être touché par cette vulnérabilité....
On préférait être sûr vu la tronche du CVE :p

DikVin

À moins d'installer des alphas partout il est improbable d'être touché par cette vulnérabilité....
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.

al_bebert

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.

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…)

bilbonsacquet

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…)
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.

Uther

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.
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.

DikVin

À moins d'installer des alphas partout il est improbable d'être touché par cette vulnérabilité....
Si on utilise des "rolling releases" (Arch Linux, Debian sid, Fedora rawhide), on a été touché.

Stéphane Bortzmeyer

Si on utilise des "rolling releases" (Arch Linux, Debian sid, Fedora rawhide), on a été touché.
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!
Modifié le 04/04/2024 à 20h41

Historique des modifications :

Posté le 04/04/2024 à 20h41


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 est doit mesurer les risques.

Et c'est bien pour ça qu'elles existent aussi!

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.
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.
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.
Ç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.

alex.d.

Ç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.
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.

atchisson

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.
Non, lancer xz --version n'appelle aucune partie du code contaminé.

alex.d.

Non, lancer xz --version n'appelle aucune partie du code contaminé.
Ç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…)
Modifié le 02/04/2024 à 21h00

Historique des modifications :

Posté le 02/04/2024 à 18h34


Ç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ébugguer.

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 bond, grub, systemd, libxml2…)

Posté le 02/04/2024 à 18h35


Ç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…)

bilbonsacquet

Ç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…)
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.
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.
Si ça n'avait pas été intercepté à temps, la backdoor aurait aussi fini par être présente dans WSL.

alex.d.

Si ça n'avait pas été intercepté à temps, la backdoor aurait aussi fini par être présente dans WSL.
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
Modifié le 02/04/2024 à 18h57

Historique des modifications :

Posté le 02/04/2024 à 18h57


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

Jean_G

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
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.
J'ai du mal à voir si ce commentaire est ironique ou non.
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 :)
Modifié le 02/04/2024 à 18h40

Historique des modifications :

Posté le 02/04/2024 à 18h40


XZ Utils ...

A une lettre près et le développeur ce serait attaqué à Nicky Larson. :transpi:
Sinon le hasard fait quelque fois bien les choses et la curiosité à du bon :)

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
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.
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)
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...
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 🤭.
Un loupé mais combien de réussites ?
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.
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.
Modifié le 03/04/2024 à 09h45

Historique des modifications :

Posté le 03/04/2024 à 09h36


Je trouve quand même qu'il devrait y avoir une forme de soutient ou des personnes de chez Github / Microsoft 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.

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...

oliv5

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...
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
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...
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.

Modifié le 03/04/2024 à 09h39

Historique des modifications :

Posté le 03/04/2024 à 09h38


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.

la complexité du truc est folle :
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
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:
Modifié le 03/04/2024 à 23h48

Historique des modifications :

Posté le 03/04/2024 à 23h46


la complexité du truc est folle :
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
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'xtérieur pourrait exécuter une charge ! :eeek2:

Posté le 03/04/2024 à 23h47


la complexité du truc est folle :
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
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'xtérieur pourrait exécuter une charge ! :eeek2:

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é.

Il a mis à jour cette semaine sa page sur xz, avec quelques 1ers détails :

https://tukaani.org/xz-backdoor/
Modifié le 05/04/2024 à 22h57

Historique des modifications :

Posté le 05/04/2024 à 22h57


Il a mis à jour cette semaine sa page sur xz, avec quelques 1ers détails :

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