Asseyez vous confortablement, prenez une boisson chaude et fermez vos réseaux sociaux. Il y a quelques jours, dans l’indifférence générale du grand public, un internaute découvre qu’une des brique logicielle de la sécurisation des données du web mondial est infectée : XZ. La grande majorité des sites web auraient pu être gravement menacés par une backdoor, une porte d’entrée cachée, qui aurait pu servir à injecter des logiciels espions, bloquer les sites, lire le données transférées ou détruire purement et simplement ces données.
L’histoire de cette infection XZ n’est pas forcément très complexe mais elle demande de saisir quelques éléments importants pour en mesurer la gravité. C’est une excellente parabole au passage sur la manière dont est gérée la plateforme internet aujourd’hui.
Pour bien comprendre ce qu’il s’est passé avec XZ, il faut commencer par le comprendre ce qu’est XZ. Il s’agit d’un composant logiciel utilisé par OpenSSH sur certains systèmes Linux. OpenSSH qui n’est rien d’autre qu’un des outils les plus massivement employés dans la sécurisation des connexion internet. C’est avec OpenSSH que de nombreux gestionnaires de serveurs pilotent leurs machines à distance. Vous savez que les serveurs, les ordinateurs qui gèrent les données des sites web que vous utilisez au quotidien, sont regroupés dans des endroits spécialisés. Des bien nommées « salles serveur » maintenues par des hébergeurs qui louent leurs machines. On utilise donc OpenSSH comme une passerelle de communication pour prendre la main sur une de ces machines à distance. Comme si on était devant en utilisant son clavier et son écran et un « tunnel » sécurisé et chiffré pour ses données et éviter toute intrusion. OpenSSH est également intégré par défaut dans une grande majorité de distributions Linux.
XZ est une petite brique de OpenSSH, un élément qui sert à gérer la compression des données de manière sécurisée. OpenSSH ayant été construit en assemblant divers éléments regroupés ensemble dans une suite logicielle. En installant OpenSSH (ou en utilisant un système Linux intégrant OpenSSH), on dispose d’un ensemble d’outils pour communiquer de manière sécurisée avec un autre réseau distant. XZ a été infecté par une Backdoor mettant en péril la très très grande majorité des liaisons sécurisées de la planète web. Voilà, c’est fini pour les présentations, passons à l’histoire.
XZ, un développement amateur sur… 22 ans
Le « coupable » est donc XZ. Ou plutôt un programmeur derrière XZ. Et c’est là que cela commence à devenir intéressant. OpenSSH c’est une tour de Jenga, vous savez ces petits blocs de bois empilés les uns sur les autres qui forment un ensemble cohérent et structuré. Et le jeu consiste à en retirer des morceaux tout en faisant en sorte que la tour tienne toujours debout. XZ est un des blocs de bois de la tour, un de ceux qui tient bon malgré un parcours assez chaotique.
Parce que XZ a été développé et maintenu par une seule personne. Lasse Collin, un développeur qui lance ce projet de compression de données sécurisé en 2000, tout seul et de manière totalement désintéressée. Il travaille dessus en le mettant à jour, l’améliorant, le faisant évoluer tout aussi bénévolement pendant deux décennies. Vous avez bien lu, une partie de la sécurité du web mondial, le truc qui permet de piloter des ordinateurs à distance de manière fiable, tient en partie au travail d’un unique et obscur bénévole sur son temps libre. Si il doit y avoir un côté grisant à se sentir partie d’un morceau du pilier qu’est OpenSSH mais aussi de milliers d’autres projets qui utilisent cette ressource de compression. De tenir à bout de bras une telle responsabilité. Je ne doute pas une seule seconde qu’il doit y avoir un côté usant également. Et, en juin 2022, Lasse Collin craque. Il annonce dans l’email ci-dessus qu’il a besoin d’aide pour continuer à s’occuper de XZ. Il est usé. Il annonce ne plus avoir l’énergie pour gérer cette brique d’OpenSSH. Vous imaginez vos Week-Ends, vacances, soirées et tout moment de la journée avec une sorte d’astreinte permanente en cas de pépin pendant des dizaines d’années ? De manière bénévole ? Dans l’ombre et en gérant sa vie personnelle et professionnelle en parallèle ? Lasse Collin est exténué et il le fait savoir avec cet email.
La communauté Open-Source est grande et pleine de talents. Son appel ne reste pas lettre morte et un volontaire se présente alors pour venir reprendre le flambeau. Son pseudo/nom est Jia Tan et si on peut s’interroger sur la motivation d’une personne à s’intéresser bénévolement à une telle « galère » il ne faut pas oublier les défis qu’elle représente. Outre le côté très motivant de reprendre un tel élément de la tour Jenga qu’est OpenSSH pour améliorer un éventuel CV. Il y a un énorme défi intellectuel à se mesurer avec ce genre de projet.
Jia Tan semble être la personne de la situation. Il n’est pas un « vieux » programmeur avec un long CV public mais semble motivé. Son compte GitHub1 a été ouvert en 2021 seulement et rien n’a été publié dessus. Mais il dialogue avec Lasse et en juin 2022, il publie sa première participation au projet XZ sous le pseudo JiaT75. Début 2023, il prend du galon et teste des nouveautés qu’il apporte lui même au code de XZ. Relâchant la pression sur son mainteneur principal. Peu à peu, il fait « ce qu’il veut » de XZ pendant que Lasse Collin s’efface et prend du repos. Plus personne ne vérifie le code en amont avant que cela soit implémenté dans XZ en général. Et donc personne ne contrôle ce qui a, petit à petit, basculé dans la « suite » OpenSSH.
En mars 2023, un changement important est fait, l’ancien email de contact du projet passe de Lasse à Jia. Désormais les requêtes, bugs et autres questions seront remontés directement vers lui. Le flambeau est passé. Plus tard dans l’année les choses avancent dans l’ombre. Des éléments sont modifiés dans le code de manière à rendre opaques de futures manipulations, des fichiers dont la vocation n’a plus rien à voir avec l’objectif de XZ sont ajoutés. Ils servent à préparer quelque chose mais cela reste totalement sous le radar.
Cliquez pour agrandir : image de @fr0gger
En février 2024, avec des stratagèmes techniques élaborés2, Jia Tan implante dans le code de XZ une porte dérobée permettant de trouer la sécurité d’OpenSSH. Les fichiers sont cachés et chiffrés. Ils sont très difficiles à débusquer car ils fonctionnent comme un poison dont on obtiendrait les effets qu’en mélangeant deux éléments à la préparation. A l’état natif, dans le code source de XZ, ils sont inoffensifs. Ils ont été ajoutés petit à petit au code dans la durée de mise à jour en mise à jour.
Pour que personne ne se rende compte du changement, puisque le code est open source et publié sur Github, la méthode employée se doit d’être d’une discrétion absolue. Ce n’est pas tous les matins qu’un programmeur émérite se lève en se disant « Tiens si j’allais auditer du code OpenSource !? » mais il suffirait qu’un curieux se penche sur le code pour que tout le plan tombe à l’eau. Autant utiliser des subtilités techniques. Le code de XZ est donc totalement propre. Il ne s’infecte que lorsqu’il est mis en place sur un serveur. XZ va alors piocher dans des fichiers annexes et se modifier pour devenir dangereux une fois en place. Vous pouvez analyser XZ de fond en comble sans rien trouver mais une fois intégré sur une machine dans OpenSSH, XZ devient la porte d’entrée du pirate. Mieux encore, le code malicieux est prévu pour être éventuellement mis à jour. Le ver est alors dans le fruit.
Si on regarde en arrière, on a donc un internaute sous le pseudo de Jia Tan qui reprend le travail de bénévole d’un autre programmeur au bout du rouleau pour maintenir un engrenage d’un des éléments de sécurité les plus importants du web mondial. Cela sans aucun autre contrôle puisque tout le monde travaille de manière décentralisée et de son propre chef. Pendant des mois, voir des années, Jia ne fait rien d’autre que ce qu’il s’était plus ou moins engagé à faire. Maintenir XZ. Il ne gagne pas d’argent, il travaille gratuitement et prépare son coup. Il semble peu probable que Jia soit un vrai nom et une vraie personne. Et c’est encore pire.
Le nom Jia Tan semble correspondre à un internaute d’origine Asiatique. Mais plusieurs experts ont noté que les fuseaux horaires de ses interventions sur le code ne collaient pas avec ceux de cette région du globe. Ils semblent plutôt viser des pays d’Europe de l’Est. On aurait voulu forger un pseudo à consonnance asiatique pour cacher un travail effectué par un groupe mafieux des pays de l’Est que l’on n’aurait pas fait autrement. Car il faut des ressources pour préparer une opération dormante sur plusieurs années. Si les intentions d’un Jia Tan étaient de simplement « faire un coup » rapide pour se faire de l’argent, il y a bien plus simple que cette opération XZ. Deux ans et demi de travail pour capter l’attention du programmeur en chef avec un compte dormant, reprendre le flambeau et intégrer un code malicieux, ce n’est pas un projet de « pirate du dimanche ». C’est une opération commanditée par un structure beaucoup plus vaste. Soit un groupe mafieux, soit un état, soit l’un employé par l’autre.
La découverte du problème XZ
Comment cette faille a-t-elle été découverte est un miracle. OpenSSH est utilisé en permanence à travers le globe, les banques, sites de eCommerce, organismes publics, armées et autres utilisateurs privés comme public emploient ce système en permanence. Et malgré cela, la faille a été découverte par « hasard » via un développeur. Si le web est gigantesque et utilisé par des milliards d’individus, le nombre d’internautes capables de trouver cette faille XZ est évidemment beaucoup plus restreint. Et, sur le total d’utilisateurs du web, un seul a su la déceler : Andres Freund.
Andres est un salarié de Microsoft, il est développeur évidemment, et c’est quelqu’un de vraisemblablement très attentif. Il travaille à l’amélioration d’un logiciel et effectue des tests variés pour cela. En faisant une mise à jour de OpenSSH – elles sont régulières – il note que sa connexion sécurisée est plus lente qu’avant. Alors pas vraiment beaucoup plus lente mais Andres est quelqu’un d’attentif et il a les outils pour le remarquer. Avant la mise à jour, la connexion sécurisée était 500 millisecondes plus rapide. Cette évolution vers la lenteur le surprend et il cherche à savoir ce qu’il se passe.
En analysant méticuleusement OpenSSH, il découvre que XZ a été modifié et qu’il contient désormais la fameuse porte dérobée mis en place par « Jia »3. Devant l’ampleur du problème, il rédige d’abord un message d’alerte à la communauté sur OpenWall qui sert à alerter les divers responsables réseau et webmestres du monde entier. Ce type de message d’alerte critique fait vite le tour du monde et des mesures de sécurité sont immédiatement prises.
Deux versions de XZ sont concernées, la 5.6.0 et la 5.6.1. Et elles ne sont pas déployées en masse. Les responsables réseaux prenant en général le temps de vérifier le bon fonctionnement des mises à jour avant de basculer les machines de production. Cette mise à jour de février n’a pas été énormément installée. « Jia » comptait probablement sur une dissémination plus ample avant de passer à l’attaque. Andres publie également sa découverte sur Mastodon. Github qui héberge le code de XZ le désactive très rapidement pour éviter qu’il ne soit exploité ou installé inopinément.
Le résultat de cette découverte évite donc le pire, les serveurs qui avaient basculé vers les dernières versions de XZ rétropédalent. Les particuliers sous une distribution Linux infectée font un retour en arrière et tout rentre dans l’ordre… On l’espère tout du moins.
Les leçons à retenir de cette histoire XZ
La première leçon est plutôt un constat. Celui d’un web mondial qui tient sur les épaules de particuliers. Quand je parle de web mondial, je ne plaisante pas. En installant une porte dérobée dans OpenSSH, les personnes derrière « Jia » avaient une arme logicielle terrifiante. Outre la possibilité de récupérer des données évidemment , il y a le risque de faire tomber des serveurs en cascade. Imaginez si plus aucun système bancaire, ferroviaire ou de santé ne fonctionnaient en même temps. Si des machines protégeant des intérêt nationaux comme de la production d’Energie ou l’armée étaient inopérantes. Si tous les hopitaux de France étaient sous le coup d’un Ransomware4.
Ce scénario est catastrophique et il est totalement plausible si l’objectif du groupe derrière « Jia » n’est pas l’argent mais plutôt à visée politique. La déstabilisation d’un pays est très facile avec une faille de cette ampleur.
Ce qui est ahurissant, c’est de se dire que la responsabilité de OpenSSH est portée par de simples particuliers. Des personnes comme Lasse Collin qui porte pendant 22 ans XZ, tout seul et sans y gagner un centime, alors que son code sert à des millions d’entreprises, établissement financiers, états et autres. Je ne pense pas que Lasse ait jamais demandé un salaire pour son travail mais cela semblerait logique qu’il soit en partie rétribué. Que les organismes qui utilisent des outils Linux mettent en pace un système de fondation permettant de maintenir les projets ne serait-ce que pour les sécuriser. Si Andres Freund n’avait pas perçu cette différence d’une demie seconde et fait le rapprochement de la mise à jour d’OpenSSH, cela aurait été un massacre. Et pourtant XZ a passé la main de son développement d’un internaute à un l’autre sans même connaitre son identité.
Andres Freund explique avoir eu énormément de chance de trouver cette Backdoor sur Mastodon.
Je ne suis pas sûr que les développeurs d’OpenSSH ou les programmeurs du monde des logiciels libres en général aient envie de devenir salariés d’une ONG globale travaillant au maintien de leur code. Je pense que beaucoup sont bien dans la situation actuelle que représente leur statut de développeurs libres. Mais il serait peut être prudent de constituer un moyen de pouvoir venir en aide ponctuellement à certains d’entre eux. Pour éviter qu’ils ne craquent comme Lasse Collin, qu’ils ne passent la main à un compte qui n’a eu à présenter aucune pièce d’identité pour devenir le rouage principal d’un élément aussi critique. Pour que l’audit des codes employés par tous les services d’assurance ou d’analyse médicale du monde soit fait régulièrement par des experts et non pas au petit bonheur en comptant sur la chance d’un programmeur attentif.
Avoir été à deux doigts d’infecter le web mondial, de récupérer toutes les données et même d’attaquer les smartphones, objets connectés et autres machines du genre, devrait faire réfléchir le monde entier sur le fonctionnement actuel du web. Le célèbre dessin de XKCD ci-dessus n’est pas neuf mais il illustre bien la situation. Toute l’infrastructure moderne du web ne tient en équilibre uniquement parce qu’un internaute le maintient seul, gratuitement et sans même un seul coup de projecteur, son bout de code dans son coin sur son temps libre. Le « gag » de cette image parle d’un internaute lambda qui ferait cela depuis 2003… La réalité c’est que Lasse Collin l’a fait pour XZ de 2000 à 2022… La réalité est plus crue que la plaisanterie et pourtant rien n’a jamais bougé.
Si cela ne vous fait pas peur, imaginez votre travail et votre vie demain si le web était par terre. Et maintenant imaginez combien d’autres pièces de ce Jenga moderne sont dans la même situation de précarité que XZ. Saisissez bien qu’une nouvelle tentative de ce genre passera par la case optimisation du code afin que ces 500 millisecondes soient ramenées au minimum également. Rendant l’acuité d’un analyste curieux inopérante. Imagines tout cela et faites de beaux rêves.
On me signale cet article de ArsTechnica qui entre dans les détails techniques de l’opération si cela vous intéresse.
Sources :
- gynvael.coldwind.pl/?lang=en&id=782
- gist.github.com/thesamesam/223
- boehs.org/node/everythin
- openwall.com/lists/oss-secu
- wiz.io/blog/cve-2024-
- https://lcamtuf.substack.com/p/technologist-vs-spy-the-xz-backdoor
- https://rheaeve.substack.com/p/xz-backdoor-times-damned-times-and
- https://www.youtube.com/watch?v=jqjtNDtbDN
- https://piaille.fr/@rusty/112190942173039817
–
Notes :
- Un site où les programmeurs de tous les pays présentent et partagent du code en ligne
- Que j’ai du mal a saisir dans leur globalité mais clairement suffisamment fins pour qu’ils soient invisibles.
- Je l’indique désormais avec des guillemets car il est vraisemblable qu’il ne s’agisse pas d’une seule personne.
- Logiciel qui oblige à payer une rançon pour débloquer la machine sous peine de voir ses données effacées.
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |
J’ai suivi cette histoire, c’est complètement fou. On est passés proche de la cata, mais qu’est-ce qui nous dit qu’il n’y en a pas d’autres qui couvent ?
Le niveau d’élaboration, la patience nécessaire… vraiment c’est une histoire de dignue, même Holywood n’y aurait pas pensé.
Et quel coup de chance d’y être tombé dessus !
Bravo Pierre pour la clarté, la clairvoyance du depelottage de ce thriller. Le pays de l’est possiblement derrière cette tentative, et d’autres, ne s’en tiendront pas là et ont peut être déjà plusieurs marrons dans le feu.
Puisse cette alerte déclencher la mise en place de contrôle, et comme tu le suggères, une implication plus forte des organismes utilisateurs, financière et opérationnelle.
Encore un poisson d’Avril ?
« Ce qui est ahurissant, c’est de ce dire que la responsabilité de OpenSSH est portée par de simples particuliers »
Tout est résumé.
Complètement dingue.
Comme toujours la faille à la base est humaine…
Difficile de croire que le dev a pu passer en quelques mois d’une personne reconnue depuis 20 ans pour son travail (bénévole) à un parfait inconnu à qui on a passé les clefs sans vérifier.
Il y a vraiment un souci de gouvernance de ses gros projets open source.
Merci Pierre pour la couverture de cette histoire affolante.
Comme dit ds l’article, les grosses multinationales qui utilisent gracieusement le travail (de qualité) de bénévoles devraient penser à rétribuer/soulager d’une façon ou d’une autre ces développeurs pour éviter ce genre de situation catastrophique.
Sinon, ce que je trouve cocasse ds l’histoire, c’est que ce soit un employé MS qui soit venu au secours du monde Open-source, ce qui devrait faire réfléchir les talibans du Libre (je précise, je suis un linuxien ascendant Windows et les guerres de clochers me fatigue) ;)
Salut,
Comme conseillé en intro, je me suis assis confortablement, j’ai pris une boisson chaude… et je me suis arrêté à ceci :
« XZ est une petite brique de OpenSSH, un élément qui sert à gérer la compression des données de manière sécurisée. »
Alors, XZ n’est absolument pas une brique d’OpenSSH ; et ne sert absolument pas à sécuriser une quelconque compression de données.
XZ sert -entre autres- à garantir l’intégrité des données compressées. Rien à voir avec la sécurisation, au sens informatique du terme, ni vis-à-vis d’OpenSSH en particulier.
Par ailleurs, le seul lien entre XZ et OpenSSH se fait par le biais de systemd (le système d’initialisation d’un grand nombre de distributions Linux, mais pas le seul). Et encore, ce lien n’est pas sytématique. Il n’est mis en place que pour mettre le serveur OpenSSH à l’écoute des notifications de systemd, ce qui n’est pas indispensable à son fonctionnement. Et c’est bien systemd qui dépend de la bibliothèque LZMA fournie par le paquet xz-utils.
Ceci étant… Comme tu l’as indiqué Pierre, cette menace n’a été que peu déployée. Comme indiqué sur la faq d’xz-utils créée pour l’occasion (https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27#misc-notes) :
« You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma) – likely only true if running a rolling-release distro and updating religiously. »
On peut donc même considérer qu’elle n’a pour ainsi dire touché « personne » (en regard des milliards d’utilisateurs connectés tous les jours à Internet), et évidemment aucun serveur digne de ce nom (c’est un métier).
Quant aux considérations philosophiques qui pourraient découler de cette histoire… rien n’a changé : à peine quelques années après l’avènement d’Internet, il est toujours aussi important de soutenir les logiciels libres, l’interopérabilité et la neutralité des réseaux. Et ça n’est pas qu’une question de finances.
Bel article et comme tout le monde je suis estomaqué j’ai l’impression de découvrir une réalité qui n’est celle que je croyais ! En bien ou en mal je ne sais pas car qui mieux que des indépendants peuvent faire sereinement un boulot sans prises d’intérêts ou délits d’initié ? Une rétribution est nécessaire ne serait-ce qu’en droit d’auteur mais aussi la création d’equipes de surveillance du réseau (IA?).
Un scénario a la James bond ! Honnêtement cette histoire de millisecondes est perturbante elle aussi… Microsoft est peut être un gendarme du web ..
Merci pour ce résumé. On a pas le cul sorti des ronces, comme on dit.
Ca m’a fait penser à cette histoire : https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code, et aussi à tous les devs qui tapent du npm install à tour de bras ;)
Par contre je suis étonné que les « méchants » aient été aussi étourdis : passer plusieurs années sur une infiltration et ne pas penser à y aller graduellement pour diffuser c’est quand même un peu idiot ou alors faut vraiment penser que l’occident est trop décadent :) ou alors ils ont un internet tellement merdique que 500 ms c’est normal pour eux
Les problèmes sont cachés par la complexité, et là, on a un exemple édifiant.
Une cascade d’erreurs : un homme seul sur un projet, un projet enfoui au fond de strates de couches logicielles, un logiciel composé de milliers de strates mais utilisés partout et par tous, des multinationales qui s’appuyent sur ces travaux bénévoles « à pas cher », des états et institutions qui utilisent les productions de ces multinationales car une multinationale « c’est du sérieux »… enfin, bref, voilà où on arrive.
Et clairement, mais si opensource et bénévole, une rétribution donation ne ferait pas du mal.
Mais tout en haut, là où y’a le pognon, on n’y pense même pas… c’est une misère en pognon pour les grands groupes, mais ce n’est même pas une question de fric, à mon avis ils paieraient sans problème. C’est juste que personne y pense, ou tout le monde s’en fout ; ça marche, on utilise, on avance. Jusqu’aux problèmes qui arrivent.
Et je rappelle que Lasse n’est pas unique dans le rôle à être seul à tenir un projet.
Vous connaissez Octoprint ? C’est une nénète qui s’occupe de ça, toute seule. Bon elle est reconnue, bon elle est financée, mais souvent elle publie qu’elle a du mal à tenir la route, tellement il y a de pression.
Certains comme Lasse fatiguent et se retirent. Mais combien pourraient se faire manipuler, voire soudoyer ?
Cette histoire ? Sûrement le dernier avertissement avant un grand BOUM.
Car, bien évidemment, personne n’en tirera les leçons.
Triste…
(je retourne me faire à nouveau une boisson chaude)
@StarDreamer: J’en profite pour remercier tous ceux qui m’en ont offert une de boisson chaude depuis la publication, de ce billet. Vous êtes supers.
@eeegr: Je pense que tu as mal lu/interprété : le premier commit de « Jia Tan » date de juin 2022 et le passage de clé a eu lieu en mars 2023. Ça permet d’apprécier le niveau technique et l’implication dans le projet à mon avis.
Certe, ça ne permet de connaitre la personne, mais je pense que les devs open source sont assez sensibles au respect de la vie privée et ne vont pas mener une enquête pour savoir exactement qui est la personne qu’ils ont « en face » d’eux, où elle est née, etc.
Et je ne doute pas une seconde que, de toute façon, un profil de « Jia Tan » ait été créé et disponible en cas de besoin.
Le problème de fond, c’est qu’aucune ressource n’est allouée par les entreprises/états pour, au moins, auditer régulièrement un projet de cette importance. Et comme le dit @StarDreamer, c’est juste qu’ils n’ont même pas conscience de l’importance de ces projets.
@Lapinou:
Bonjour,
Personne pas tout à fait vrais.
Les utilisateurs des distributions Rolling Release à jour ont été impactés (Tumbleweed sûr, je suppose qu’il en est de même pour arch and co, ainsi que gentoo?), Fedora il faudrait creuser selon la version, et debian la branche testing et SID ont eu l’ensemble des briques déployées durant un moment, donc tous ceux utilisant ces distributions avait potentiellement l’ensemble des conditions réunies pour qu’elle soit exploitable.
On est d’accord ça exclue 99% des serveurs en production (le % restant étant ceux qui ont la bonne idée de faire tourner leurs serveurs, ou conteneur docker sur une rolling release), mais pour les utilisateurs c’est potentiellement plus large.
@Lionel: @Lionel: suis d’accord, une des solution serait peut être un système de « certificats » pour les devs open source…
Il faut préciser que ce code malicieux a en réalité eu très peu d’impact, voir pas du tout.
Même si on est sous Arch ou Fedora 40, il y a très peu de chance que l’ordi est été compromis. Tout simplement parce qu’il faut avoir sshd d’activé. Si le serveur ssh n’est pas installé et activé, même avec les versions incriminées d’xz, l’impact est nul.
Et franchement, faut être soit un guignol, soit un sportif pour installer une rolling release (Arch, Debian testing et sid) ou une version de développement (F40) sur un serveur.
Pour moi, justement, une des leçons de cette histoire, c’est qu’une rolling release est tout sauf le top question sécurité.
Longue vie à Debian stable.
@toto: C’est précisé dans le billet et par @Lapinou plus haut.
@gUI: pour le coté « personne ne l’a vu venir » c’est plutôt faux. Il y a tout un tas d’articles de blog spécialisés qui parlent du risque et ça depuis au moins 3 ans. Le soucis c’est que la raquette est énorme.
@Pierre: Attention avant de pointer un pays du doigt. Ca pourrait aussi être une équipe de chez nous, ca recrute fort à la DGSE depuis un moment, on a aussi les compétences techniques et tout le monde sur terre utilise linux, donc on a des intérêts. En réalité ça pourrait être n’importe qui.
Il faut bien comprendre que l’attaque est suffisament sophistiquée. C’est pas le seul projet open-source qui ait des raisons légitimes de mettre en oeuvre des blobs binaires. Ca aurait pu arriver à beaucoup d’autres projets. Rien ne dit qu’un projet avec une équipe plus étoffée aurait vu venir le problème à moins que cette équipe comporte un spécialiste sécurité (ou quelqu’un avec une affinité en ce sens).
C’est pas beaucoup mieux du coté des micro-logiciels, ceux qui fonctionnent sur les puces des composants de nos machines tels que les carte son, carte graphiques, disques durs, ssd et compagnie. Ce sont pour l’essentiel des blobs binaires qui viennent d’entreprises réparties partout dans le monde, dont on connait parfois le code source mais souvent pas la chaine de construction. Aucune garantie que ces entreprises n’aient pas confié le projet à une équipe unipersonelle.
Et si on rentre dans la paranoïa : qui contrôle le TLS et quelle implication en cas de fuite d’une clé racine de Comodo (sous la pression du patriot act par exemple) ?
Il ne faut pas oublier qu’ici c’est une vecteur potentiel de code malicieux qui a été mis au jour. Des vecteurs il y en a d’autres mais surtout il y a beaucoup d’outillage défensif pour contrer les exploitations de ces vecteurs, ainsi que des équipes et des procédures pour identifier, tracer, neutraliser les menaces. On n’est pas complètement à poil mais c’est sûr que les particuliers n’ont pas vraiment le luxe d’un haut niveau de sécurité. C’est vrai pour tout : un chateau d’eau est mieux protégé qu’un receveur d’eau de pluie.
Pour en revenir au sujet très précis : les problématiques de sécurité de la « supply chain » numérique sont très actuelles. Le cadre règlementaire et technique évolue. Mais la sécurité absolue ça n’existe pas, on fait au mieux avec les menaces et les contraintes.
L’écosystème numérique, notamment open-source, grossit et évolue à une vitesse folle et même si on trouvait de l’argent pour payer tout le monde il n’y aurai tout simplement pas assez de temps de cerveau pour tout maintenir. La détresse psychologique des contributeurs ne vient plus forcément de la précarité financière mais de l’ampleur de la tâche. Par forcément de maintenir un projet, mais d’en maintenir 10 parcequ’on se fait facilement haper, ça plus le boulot, la famille… Ceux qui veulent aider doivent apprendre à coder, c’est une approche moins hasardeuse que d’espérer que l’IA vienne nous sauver à temps. Aujourd’hui on a une situation paradoxale où l’informatique est bien vue, c’est cool et à la mode, ça paie bien, et on galère toujours autant à trouver assez de personnel qualifié.
Chaud chaud chaud, l’illustration de XKCD est à encadrer dans tout centre de DSI qui se respecte
Je suis pour ma part un peu surpris de tant d’efforts pour se ménager un accès SSH qui est sans doute ce qui est le plus ciblé: Même à titre personnel, ceux qui auto-hébergent par exemple un serveur HTTPS et un SSH ont eu tout loisir de se rendre compte de la colossale différence de ciblage et des mesures à prendre pour le second à tout niveaux (limitations d’accès, configuration du serveur, surveillance des connections) tandis que du côté du 1er, cela reste très calme.
=> Quel intérêt à mettre tant d’énergie à placer sa clef SSH dans un parc croissant (lentement, au fil des MAJ) en espérant pouvoir y accéder plus tard sans connaître ceux qui seront affectés (il faudra donc tenter à l’aveugle, pour se faire griller en quelques heures) si on veut une action d’ampleur… ou tenter son coup sur quelques systèmes d’intérêt et y laisser des traces infructueuses qui seront repérées, certes plus tardivement, ou réussir pour n’avoir dans l’immédiat au mieux qu’un accès à un compte utilisateur (éventuellement sudoer, ce qui ne change pas le pb qui suit) duquel il faudra tenter l’escalade root, plus personne n’étant assez fou pour autoriser l’accès ssh root direct. Chose qui sur tout système d’intérêt fatalement correctement administré, va lever une alerte et un blocage automatique/immédiat: C’est pas comme si se mettre sa clef SSH root n’avait pas été un moyen très utilisé par toute personne ayant un accès physique aux machines dans une société afin de contrer des IT qui vous emmerdent pour vous donner quelques droits nécessaires à votre boulot ou simplement installer avec diligence les outils dont vous avez besoin… Je l’ai fait, mais désormais ce ne serait plus possible.
On verra ou l’analyse détaillée va mener, possible que celui qui a fait le coup se retrouve aussi avec sa résistance éprouvée à une quelconque gégène, mais pour ma part j’avoue être un peu surpris de voir un ssh surveillé comme le lait sur le feu ainsi ciblé avec des traces qui n’ont aucune chance de passer inaperçu vu le passif.
@J: » Attention avant de pointer un pays du doigt. » J’ai fait attention puisque je ne l’ai pas fait.
j’avais pas du tout suivi, juste vu passer sur ars la news et vu le pavé j’avais remis à plus tard la lecture.
Merci pierre pour ce bel article, explicatif et facile à lire dans notre langue!!
Pour avoir collaboré à certains projets open source, c’est le gros problème, une brique utile peut ne plus avoir personne pour la maintenir, et si tu fais parti des 4 personnes dans le monde à t’en servir tu te retrouves le bec dans l’eau sur le reste de ton projet.
Et le fait que toute les grosses boites utilisent sans vergogne ni contribution tout ce code est un peu déprimant, un bel idéal renforce les boites capitaliste. :(
@Raph: dans toute boite en fait. Le système capitaliste est friand d’une structure Jenga, où le travail repose sur les épaules d’une seule (ou de peu de) personne qui produit les resources ou le service, et de toute une cohorte qui vie de la valeur ajoutée sur cette production.
Collin Lasse est comme les agriculteurs, les personnels de l’éducation, etc. qui tiennent notre société debout à peu de frais (i.e. pour un salaire 10 à 20 fois inférieur aux chargés d’audit de chez Mac Ki(n)sey(pas) et Cap Chuimini) : on ne sait pas si on doit les ériger en héros pour avoir porter cela pour le bien de l’humanité ou bien les avoir en pitié de se faire ainsi exploiter.
L’avantage avec windows c’est qu’on ne sait pas ce qu’il y a dedans (dont probablement 90% de repompage des systèmes libres, peut-être ce xz copié/collé, d’où les contributions régulières à peu de frais de ces grosses boites à saupoudrer le libre pour développer des outils qui leur couteraient beaucoup de dividendes à développer eux-même et à maintenir)… les failles peuvent donc s’y faire discrètes et ainsi, les moutons de Panurge venir déblatérer sur le libre, pensant que « si c’est caché du grand public, c’est mieux ».
Merci à Lapinou et à Pierre pour leurs précisions qui ne vont pas dans le travers de Sidero … « taliban du libre », sérieux ? Une formule aussi stupide qu’Ecoterroriste qui passe allègrement la barrière du çon, mais tant qu’il y en aura pour tout oser et que ça passe, pourquoi ne pas s’en priver !
Sinon, une piqure de rappel pour pointer du doigt que la stratégie des « talibans du libre » à la Debian de ne mettre que du code audité, usé et réusé dans un système pour des raisons de sécurité est bien la seule stratégie valable. Ce processus de « relecture » par des pairs du code, un processus commun avec le processus scientifique et le journalisme (le vrai, celui d’investigation, pas l’éditorialisme), est un processus qui demande du temps, des gens et de l’énergie. Aucun code publié sans relectures indépendantes par plusieurs groupes/nationalité/sensibilités ne devrait être poussé en production à large échelle.
Donc le schéma libre de développement est le bon sur la sécurité, à condition que le facteur temps et humain (donc de mutualisation/intelligence collective, et pas de chacun pour soi dans son coin avec son petit moyen comme promu par le propriétaire), gourmand en ressources, soit à échelle de l’importance du projet pour l’infrastructure.
@Pierre Lecourt: je parlais à l’autre Piere ^
@J: Ah ! Mea maxima culpa !
Excellent article, très bien écrit, merci Pierre (Lecourt !) :)
@Franck:
Ce qui est aussi ahurissant c’est qu’un gus d’une grosse boîte (au hasard Microsoft) découvre la faille et ne finance rien pour la corriger en prenant les volontaires comme des sous-fifres… C’est aussi le soucis de ces grosses boîtes qui utilisent des briques open-source sans financer derrière.