Dredi, Andres Freund découvre par hasard une backdoor dans la librairie xz utilisée notamment par une grande partie des serveurs ssh. Je crois pas que ce soit le cas de dropbear par exemple, mais j’ai pas regardé.
Pour les distributions basées sur debian, la backdoor est présente dans unstable. Bref la chose que tout bon chaton évite en production à moins d’être aventureux (ou de vouer un culte à sid.)
Chez vous, vérifier l’état du paquet installé avec votre utilitaire favori par exemple dpkg -l xz-utils Les versions upstream compromises et à éviter seraient XZ Utils 5.6.0 and 5.6.1
Toutefois, la backdoor est inédite par la manière employée pour l’introduire dans la librairie. Le détail est disponible ici https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024
Et de fait, il serait nécessaire de revenir à la version 5.3.1 sauf que cela casse d’autre paquet comme dpkg.
Une version antérieure ou égale à 5.3.1 pourrait être considérée comme safe. Sauf qu’il y a un débat pas encore bien calé. Et on arriverait tranquillement à considérer 5.2.5 comme un bon compromis. Sauf que là on est déjà remonté à ubuntu 22.04 par exemple. C’est peut-être le moment pour considérer de mettre en place un knock knock voire un bastion.
À priori le package manager Nix emploie également xz comme utilitaire de compression|décompression.
Point de vigilance, la backdoor ne concernerait pas uniquement openssh ou les packages manager mais plus largement systemd. C’est à dire tous les os basés sur le noyau linux. Ce qui complique pour beaucoup toute régression si on souhaite revenir à une version saine ou identifiée comme saine car exempte de commit « jy lay »
Unlike other Linux distribution, where stable releases are preferred, nixos-unstable is widely used by Nix community, especially flakes.
I think it is worth to announce this CVE and recommend any projects depending on nixpkgs between #291205 and #300028 to switch to a different nixpkgs revision.
J’ai pas tout lu. Un avis plus avisé chez nos ami·es de Deux-Fleurs ? poke @quentin ?
Hello Stéphane, nixpkgs est utilisé par « Nix l’outil compagnon à ton OS » et « NixOS la distribution Linux ».
À Deuxfleurs, on utilise les deux pour des trucs différents : le premier pour packager Garage & co, le second pour nos serveurs.
NixOS la distribution Linux distingue bien les versions stables et instables (ce sont des branches différentes sur le repo nixpkgs), on peut voir par exemple que la version stable 23.11 de NixOS a un xz en 5.4.4, et la version unstable en 5.4.6. La version qui contient la backdoor est la 5.6.x. Il y a bien eu la 5.6.x de publiée sur unstable, mais le rollback a eu lieu il y a quelques heures, après un rebuild massif selon le fil que tu cites plus haut. Et du coup la 5.6.x n’est jamais arrivée sur la branche stable 23.11 dédiée à NixOS, et on est donc pas impacté à ce niveau.
Je lis bien que suite à cette backdoor trouvée dans la 5.6.x, il y a un doute sur les autres commits de Jia Tan et une volonté d’expurger tout ses commits et de remonter à la version 5.3.x. Personnellement je ne compte pas être proactif sur cette voie et, à la place, m’aligner sur ce que proposeront les maintainers de nixpkgs.
Quant à « Nix le compagnon », les dépendances sont gelées dans un fichier flake.lock, et bump une toolchain de compilation est pas un truc qu’on fait souvent. On a pas fait ce genre de trucs dans le court laps de temps où le patch était en ligne.
Je me rends compte que j’ai essayé de faire un jeu de mot sur le patronyme de l’auteur des commits afin de me moquer un peu de la team GE from Thalès . Mais que ça n’a pas marché. Afin d’être explicite, et d’après les adeptes, il s’agirait forcément d’un coup des russes ou forcément d’un coup des chinois ou forcément d’un coup des US selon votre sensibilité impérialiste.
À priori, il y aurait deux propositions pour se passer de xy.
La team «facebook va nous sauver»
La première est de trouver un concurrent plus sérieux avec zstd. Il s’agit d’une librairie développée par un bataillon de gens, pardon, de data scientist, de chez facebook. C’est sur que ça force le respect face à une seule personne qui avait pas forcément demandé à devenir une star filante.
À priori, les disciples de cette team frôlerait de peu les limite acceptable de dieu Shanon. Qu’en pense @oiseauroch ?
Il y a une double licence bsd | gpl v2. Quelqu’un peut m’expliquer c’est quoi l’intêret de la double licence ?
La team «systemd est trop bavard»
L’autre proposition est de modifier la succeptibilité actuelle de systemd au bavardage et à la nécessité de decompresser|compresser ce flux continuel de notification. On peut faire une analogie avec nos réseaux sociaux. Des vieux barbus pourraient se réveiller en disant «on vous l’avez bien dit» que ça ne changerait rien car la voie est empruntée. Et on va pas refaire la guerre systemd vs system init.
Les infos sur cette issue fermée car trop hot Reduce dependencies of libsystemd · Issue #32028 · systemd/systemd · GitHub
Je me demande tout de même si il ne faudrait pas relire Isabelle Stengers et Illya Prigogyne. Dans la nouvelle alliance iels expliquaient tout ça dès 1979. Mais peut-être que nous sommes face à une nouvelle limite de l’anthropocène liée à nos limites mémorielles ?
@stephane : ou encore : l’opensource est vulnérable.
Les projets opensource sont développés par des individus ou des groupes d’individus auquels nous n’avons d’autre choix que de faire confiance, car personne n’est capable de tout vérifier ni de tout redévelopper.
Dans l’immense majorité des failles rencontrées jusqu’à maintenant dans les logiciels opensource, il s’agissait de vulnérabilités involontaires. Ces vulnérabilités étaient parfois exploitées par des gouvernements plusieurs mois avant leur découverte par la communauté.
Ce que je trouve marquant dans cette affaire, c’est qu’il ne s’agit pas d’une erreur involontaire mais de toute évidence d’une backdoor ingénierée et offusquée pour tenter d’éviter sa découverte. Je n’ai pas souvenir de backdoors insérées dans des logiciels opensource par le passé, à ma connaissance, dans les cas précédents il s’agissait de logiciels ou produits propriétaires.
En supposant qu’il s’agissait dès le départ de son objectif, on peut dire que la personne à l’origine de la backdoor a attaqué le projet par social engineering. On peut imaginer qu’elle a ciblé un projet vulnérable par nature car faiblement maintenu, qu’elle a fourni progressivement des contributions de plus en plus importantes, jusqu’à obtenir l’accès aux releases (moyen qui a été utilisé pour diffuser la compromission), avant de commencer à se comporter comme un acteur malicieux lorsqu’elle a estimé avoir acquis la confiance du mainteneur principal et de la communauté.
Je pense qu’une telle attaque, quelle qu’en soit l’origine (organisation gouvernementale à 3 ou 4 lettres ou autre) et quel qu’en soit l’objectif, n’a rien d’étonnant. Et je pense que cela devrait peut-être nous faire nous interroger sur notre confiance vis à vis des logiciels qu’on utilise et vis à vis de nos contributeurs.
Peut-être n’y a-t-il pas de solution, peut-être y en a-t-il une. Toujours est-il que le problème selon moi n’est pas technique, il est humain.
Je plussoie sur l’origine humaine, qui illustre une nouvelle fois la difficulté de vivre décemment d’une activité éthique.
La 1ère difficulté pour la pérennité d’un projet logiciel libre, c’est de faire en sorte que la solution soit largement utilisée… et la seconde d’arriver à trouver un financement pour que la maintenance soit à la hauteur (et lycée de Versailles)!
La technique arrive bien loin après.
