Le premier piratage de l'Internet : Un bénévole a failli faire tomber Linux

Cinq cents millisecondes.

Une demi-seconde.

La marge de temps qui a empêché le piratage d'Internet.

Mars 2024. San Francisco.

Un ingénieur Microsoft de trente-huit ans nommé Andres Freund procède à l'évaluation comparative de PostgreSQL sur un système de développement Debian. C'est une tâche de routine. Freund est un committer sur le projet PostgreSQL. Il teste les performances des bases de données sur des distributions Linux en pré-version, ce qui fait partie intégrante de son travail.

Quelque chose ne va pas avec l'environnement de test.

Les tentatives de connexion SSH échouées — celles qui frappent constamment chaque serveur public, des bots automatisés essayant des combinaisons aléatoires de noms d'utilisateur et de mots de passe — utilisent beaucoup plus de CPU qu'elles ne le devraient. Une connexion échouée devrait se terminer rapidement. Celles-ci ne se terminent pas rapidement.

Freund le remarque.

Il enquête plus en détail. Les connexions SSH réussies, sur sa propre machine locale, prennent cinq cents millisecondes de plus que la référence d'environ cent millisecondes.

Une demi-seconde.

Freund exécute la connexion sous Valgrind, un outil de débogage de la mémoire. Valgrind signale des erreurs pointant vers liblzma — une bibliothèque de compression que le daemon SSH n'a aucune raison légitime d'invoquer.

C'est là que l'enquête devient urgente.

Au cours des jours suivants, Freund retrace les erreurs. Il découvre que le processus sshd sur sa machine de test exécute du code de liblzma pendant l'authentification. Il dissèque la source de xz-utils dans le dépôt git. La source est propre. Mais le tarball de la version — l'archive source compressée que Debian télécharge et compile réellement — contient un fichier appelé build-to-host.m4 qui ne se trouve pas dans la source git.

Ce fichier contient un script obfusqué. Le script décode un script bash caché à l'intérieur d'un fichier de test appelé bad-3-corrupt_lzma2.xz — un fichier déguisé en entrée de test corrompue pour la gestion des erreurs de la bibliothèque de compression. Le script bash décode un second fichier, good-large_compressed.lzma, en utilisant une obfuscation personnalisée combinée au déchiffrement RC4.

Ce qui en ressort à la fin de la chaîne est un objet partagé compilé.

L'objet partagé est une porte dérobée.

Dans la soirée du vingt-neuf mars 2024 — alors que, selon ses propres dires, il écoutait un podcast sur la sécurité pendant une pause cuisine — Andres Freund publie ses découvertes sur la liste de diffusion oss-security à Openwall.

En moins de 24 heures, Red Hat lui attribue un numéro CVE. Le score de gravité est de dix virgule zéro. Le plus élevé possible. CISA émet un avis d'urgence. Debian, SUSE, Fedora, Arch et Kali annulent tous les paquets affectés. GitHub suspend le compte du mainteneur qui a commis la porte dérobée.

La porte dérobée, il s'avère, devait être livrée avec les distributions Linux stables dans un délai d'environ deux semaines.

Freund l'a découverte par accident.

Voici le dossier sur ce qui s'est passé. Sur ce qui a failli se passer. Et sur ce qu'était l'opération.

La cible de l'attaque était xz-utils.

xz-utils est une boîte à outils de compression. Son outil principal, la commande xz, produit des fichiers .xz — l'équivalent Unix des fichiers .zip, avec des taux de compression plus élevés. Sous l'outil en ligne de commande se trouve une bibliothèque appelée liblzma, qui fournit l'algorithme de compression à d'autres programmes qui en ont besoin.

liblzma est chargée, directement ou indirectement, par une quantité énorme de logiciels système Linux. Les gestionnaires de paquets s'y lient. Les utilitaires système s'y lient. Et — à travers une chaîne que les attaquants ont spécifiquement conçue — le daemon OpenSSH s'y lie.

La chaîne fonctionne comme ceci. Sur la plupart des grandes distributions Linux, sshd est patché pour prendre en charge le mécanisme de notification de service de systemd, appelé sd_notify. Ce patch fait que sshd charge une bibliothèque appelée libsystemd. Et libsystemd, à son tour, charge liblzma.

Le résultat : sur la plupart des serveurs Linux de production, le daemon SSH — le processus qui accepte les connexions à distance — charge une bibliothèque de compression au démarrage, même si SSH ne compresse pas le trafic d'authentification.

Compromettez la bibliothèque de compression, et vous compromettez le daemon qui contrôle l'accès à distance à chaque serveur Linux sur Internet.

Au moment du quasi-déploiement de la porte dérobée, Linux faisait tourner environ quatre-vingt-seize pour cent du million de serveurs web les plus importants au monde. Les cinq cents superordinateurs les plus puissants du monde. Environ quatre-vingt-douze pour cent des machines virtuelles sur Amazon Web Services, Google Cloud et Microsoft Azure. Android, qui alimente environ quatre-vingt-cinq pour cent des smartphones mondiaux, est basé sur le noyau Linux.

La porte dérobée xz-utils, si elle avait été livrée aux distributions stables, aurait été présente dans une fraction substantielle de tout ce qui précède.

Alex Stamos, l'ancien directeur de la sécurité de Facebook, a décrit le résultat escompté en une phrase : une clé maîtresse pour n'importe quel serveur SSH sur Terre.

C'est pourquoi le CVE a été noté dix virgule zéro.

La conception technique de la porte dérobée mérite d'être comprise précisément.

L'attaquant a exploité le fait que les tarballs de version contiennent des fichiers auto-générés qui n'existent pas dans la source git contrôlée par version. Plus précisément, le fichier build-to-host.m4 dans le tarball contenait une seule ligne qui avait été modifiée pour injecter un script obfusqué dans l'étape de configuration du processus de construction.

Cela signifiait que quiconque lisait le code source git ne pouvait pas voir la porte dérobée. Quiconque construisait à partir de git ne pouvait pas la déclencher. Seules les distributions Linux, qui construisent à partir des tarballs publiés — c'est-à-dire pratiquement toutes — exécuteraient l'injection.

La chaîne d'injection comportait trois étapes. La première étape extrayait un script bash d'un fichier déguisé en entrée de test de compression corrompue. La deuxième étape utilisait ce script bash pour décoder un deuxième fichier de test en un objet partagé compilé. La troisième étape liait l'objet partagé au binaire liblzma compilé.

L'objet partagé utilisait une fonctionnalité légitime de glibc appelée IFUNC — indirect function resolvers — pour détourner une fonction OpenSSH spécifique appelée RSA_public_decrypt.

RSA_public_decrypt est la fonction OpenSSH qui valide les signatures RSA lors de l'authentification par certificat. Chaque fois qu'un client tente de se connecter en utilisant un certificat RSA, sshd appelle cette fonction pour vérifier la signature.

Avec la porte dérobée active, sshd appelait le code de l'attaquant à la place.

Le code de l'attaquant inspectait le module public RSA — la grande valeur entière passée dans le certificat du client. Normalement, cette valeur est utilisée dans la vérification RSA standard. Dans la porte dérobée, il s'agissait en fait d'un conteneur de charge utile. Le code déchiffrait la charge utile en utilisant une clé symétrique ChaCha20 codée en dur. Ensuite, il vérifiait la signature de la charge utile déchiffrée en utilisant une clé publique Ed448 codée en dur.

Si la signature était vérifiée — ce qui signifiait que la charge utile était signée par la clé privée de l'attaquant — le code exécutait les commandes shell intégrées en tant que root.

C'est ce que les chercheurs en sécurité appellent l'exécution de code à distance gardée. La porte dérobée ne s'active que lorsque l'attaquant présente une signature cryptographique valide. Un attaquant ordinaire qui tombait sur la porte dérobée ne pouvait pas l'exploiter. Seul le détenteur de la clé privée Ed448 pouvait la déclencher.

Ce détail est important. Un acteur criminel construisant une vulnérabilité à vendre la rend utilisable par quiconque l'achète. Un acteur étatique construisant une capacité d'accès persistante la rend exclusive. Seuls eux, et toute personne qu'ils autorisent explicitement, peuvent utiliser la clé.

La porte dérobée xz-utils a été conçue pour un usage exclusif. Ce n'était pas une vulnérabilité. C'était un atout stratégique.

L'opération qui a produit la porte dérobée a commencé le vingt-six janvier 2021.

À cette date, un compte GitHub a été créé sous le nom d'utilisateur JiaT75. Le nom d'affichage était Jia Tan. Le compte n'avait aucune empreinte numérique antérieure. Aucune présence sur les réseaux sociaux sous ce nom. Pas de conférences. Pas de contributions open-source antérieures. Aucune apparition dans les fuites de données. Le nom semble être un pseudonyme.

La première contribution publique de JiaT75 à xz-utils a eu lieu le vingt-neuf octobre 2021 — neuf mois après la création du compte. Il s'agissait d'un patch mineur pour un fichier de configuration d'éditeur. Inoffensif. Sans importance. Le genre de contribution qui établit une présence sans attirer l'attention.

Au cours des deux années et cinq mois suivantes, JiaT75 a créé plus de cinq cents commits pour des projets open-source. La grande majorité étaient des améliorations légitimes — révisions de code, traductions, maintenance de l'intégration continue, corrections de bugs. Un travail utile. Vraiment utile.

Environ huit de ces commits étaient malveillants.

Le ratio est important. Soixante pour un. Pour chaque commit malveillant, l'opérateur a produit soixante pièces de travail réelles et utiles. C'est ce qui a rendu le modèle impossible à détecter par l'analyse statistique des anomalies. L'attaquant a passé deux ans et demi d'efforts dédiés à produire des contributions véritablement précieuses, uniquement pour accumuler la confiance requise pour effectuer les huit changements qui importaient finalement.

L'opération n'a pas travaillé seule.

À partir d'avril 2022, un utilisateur se faisant appeler Jigar Kumar est apparu sur la liste de diffusion xz-devel. Kumar n'avait aucun historique sur la liste avant avril 2022. Toute sa présence consistait en des e-mails de pression au mainteneur principal du projet, se plaignant des longs délais de réponse et exigeant l'ajout d'un nouveau mainteneur.

En mai 2022, un deuxième compte — Dennis Ens — est apparu, s'informant de l'état de la maintenance de la version Java de xz-utils, et poursuivant avec des messages de pression supplémentaires.

Les deux comptes avaient le même profil. Aucune présence numérique avant 2022. Aucune activité en dehors de la liste de diffusion xz-devel. Aucune participation à d'autres projets avant ou après la campagne de pression.

En février 2024 — des semaines avant que la porte dérobée ne soit commitée — un troisième compte est apparu. Hans Jansen. Le rôle de Jansen était de faire pression sur les mainteneurs Debian pour qu'ils adoptent la version compromise de xz-utils dès que possible. Le vingt-cinq mars 2024, Hans Jansen a déposé un rapport de bug Debian demandant explicitement la mise à niveau.

Quatre jours plus tard, Andres Freund a publié ses découvertes sur oss-security.

Deux comptes de soutien supplémentaires — krygorin4545 et misoeater91 — ont exercé une pression de fond dans divers fils de discussion, suivant le même modèle. Aucune présence avant l'opération. Participation uniquement pendant des fenêtres de pression spécifiques. Disparition après l'atteinte des objectifs.

L'analyse post-incident de Kaspersky a noté que le style géographique des noms des sock-puppets était incohérent — Singaporean, European, Indian — suggérant que l'opérateur avait délibérément dispersé les identités de couverture pour éviter l'apparence de coordination. Mais le modèle comportemental — calendrier des apparitions, points de pression synchronisés, disparition collective après chaque objectif — suggérait un seul opérateur ou une équipe étroitement coordonnée.

La pression a fonctionné.

Le vingt-neuf juin 2022, le mainteneur principal de xz-utils — un développeur de logiciels finlandais nommé Lasse Collin — a répondu à la liste de diffusion et a déclaré que Jia Tan aurait un rôle plus important dans le projet à l'avenir, et fonctionnait, en pratique, déjà comme co-mainteneur.

C'était le transfert.

Pour comprendre ce qui venait de se passer, il est nécessaire de comprendre la position de Lasse Collin.

Collin maintenait xz-utils, seul, depuis 2009. Le projet n'était pas rémunéré. Il y travaillait pendant son temps libre. Plus tôt le même mois, dans une réponse à la liste de diffusion de juin 2022, Collin avait publiquement reconnu qu'il était aux prises avec des problèmes de santé mentale à long terme. Il a qualifié le projet, selon ses propres mots, de projet de loisir non rémunéré.

Lasse Collin n'est pas responsable de ce qui s'est passé. La communauté de la sécurité est unanime sur ce point. Collin faisait un travail de loisir non rémunéré. Il faisait face à des problèmes de santé documentés. Il était sous une pression soutenue et coordonnée de ce qui s'est avéré être une opération de renseignement au niveau étatique. Le système qui l'a placé dans cette position l'a trahi. Il n'a pas trahi le système.

Ce que l'opération a exploité, ce n'était pas la compétence de Collin. C'était sa position structurelle — seul, non rémunéré, aux prises avec des facteurs de stress du monde réel, responsable du maintien d'une infrastructure utilisée par des milliards de personnes, sans soutien institutionnel.

L'attaquant professionnel a identifié cette structure et l'a ciblée.

Une fois le transfert terminé, la préparation de l'infrastructure a commencé.

En octobre 2022, Jia Tan a été ajouté à l'organisation Tukaani sur GitHub. En décembre 2022, il a créé la structure organisationnelle du dépôt et a effectué sa première version. En mars 2023, il a changé l'adresse e-mail de contact de sécurité principale chez Google's OSS-Fuzz — la plateforme automatisée de détection de vulnérabilités — de l'adresse de Lasse Collin à la sienne. À partir de ce moment, tout rapport de bug pertinent pour la sécurité atteindrait Jia Tan avant d'atteindre quiconque.

En juin 2023, Jia Tan a introduit l'infrastructure de résolution IFUNC dans liblzma. Les commits semblaient être un travail légitime d'optimisation des performances. Rétrospectivement, il s'agissait des crochets par lesquels la porte dérobée serait finalement injectée.

En juillet 2023, Jia Tan a ouvert une pull request sur OSS-Fuzz pour désactiver le fuzzing IFUNC pour xz. Le changement visait à empêcher le pipeline de test fuzz de détecter des anomalies dans la porte dérobée basée sur IFUNC lorsqu'elle serait finalement livrée.

En février 2024, un commit distinct a cassé la détection par le système de build de Landlock — une fonctionnalité de sécurité du noyau Linux qui restreint les privilèges des processus. Le commit a désactivé le propre sandbox de xz sur les systèmes qui l'auraient autrement appliqué.

Les vingt-trois février et neuf mars 2024, la porte dérobée elle-même a été commitée en deux étapes, empaquetée dans les versions xz-utils 5.6.0 et 5.6.1.

Dix-neuf jours plus tard, Andres Freund a remarqué un délai SSH de 500 millisecondes.

Les chercheurs analysant les métadonnées de commit laissées par l'opération ont remarqué un modèle.

Les horodatages des commits de Jia Tan se concentraient principalement dans les fuseaux horaires d'Europe centrale ou d'Europe de l'Est. Les heures de travail correspondaient à environ neuf heures du matin à cinq heures de l'après-midi, heure d'Europe centrale. L'activité s'est poursuivie pendant les principales fêtes publiques chinoises et s'est interrompue pendant plusieurs fêtes européennes.

Le nom, et la géographie opérationnelle revendiquée, étaient est-asiatiques. Le modèle de travail réel était européen.

C'est ce que les analystes du renseignement appellent une fuite de signature. Un opérateur a passé plus de trente mois à maintenir une identité de couverture. Mais les horodatages automatiques intégrés dans chaque commit git révélaient périodiquement l'emplacement réel de la machine qui effectuait le commit.

Trois attributions possibles sont apparues dans l'analyse publique de chercheurs en sécurité ayant une expertise pertinente.

Le chercheur en sécurité américain Dave Aitel, ancien informaticien de la NSA, a publiquement estimé que l'opération correspondait au modèle attribuable à APT29 — le groupe de menace persistante avancée attribué par les gouvernements des United States et du United Kingdom au Service de renseignement extérieur de la Russia. APT29 est connu pour ses campagnes d'espionnage de longue durée, y compris le compromis de la chaîne d'approvisionnement SolarWinds révélé en 2020. Les heures de travail alignées sur le fuseau horaire de Moscow correspondent au modèle de Jia Tan.

Costin Raiu — l'ancien directeur de la Global Research and Analysis Team de Kaspersky, avec trois décennies d'expérience dans l'attribution d'opérations sophistiquées — a identifié trois candidats plausibles dans une interview de podcast de février 2026. L'APT29 de la Russia en était un. L'APT41 de la China, associée au Ministry of State Security, était un second. Le Lazarus Group de la North Korea, déjà présenté dans une couverture antérieure de Fragment Zero, était un troisième.

En avril 2026, aucun service de renseignement n'a publiquement attribué l'opération. Aucune inculpation n'a été déposée. Aucune arrestation n'a été effectuée. La véritable identité de Jia Tan reste inconnue.

Ce qui n'est pas contesté, parmi les chercheurs ayant une expertise pertinente en matière de techniques opérationnelles, c'est que la patience de l'opération, sa sécurité opérationnelle, sa sophistication cryptographique et son engagement en ressources sont cohérents avec un service de renseignement d'État — ou un équivalent fonctionnel proche — et sont incompatibles avec une activité criminelle individuelle ou hacktiviste.

Ce n'était pas l'œuvre d'un hacker solitaire.

L'opération xz-utils a été possible grâce à une caractéristique structurelle de la façon dont la civilisation technologique moderne construit son infrastructure critique.

Le logiciel qui fait fonctionner Internet a été construit, dans une large mesure, par des bénévoles travaillant sur leur temps libre. Les entreprises qui profitent de ce logiciel n'ont reversé qu'une petite fraction de sa valeur économique.

xz-utils était intégré à toutes les principales distributions Linux et fonctionnait sur une fraction énorme des serveurs mondiaux. Son mainteneur n'était pas rémunéré. OpenSSL, la bibliothèque qui fournit la cryptographie à la majeure partie d'Internet, était notoirement en sous-effectif avant la vulnérabilité Heartbleed en 2014. Log4j, la bibliothèque de journalisation Java derrière la vulnérabilité Log4Shell en 2021, était maintenue par une poignée de bénévoles — derrière l'infrastructure d'entreprise mondiale.

Dans chaque cas, une bibliothèque traitée comme une infrastructure critique par des entreprises valant des milliards de dollars était maintenue avec les ressources d'un projet de loisir.

L'opération xz-utils n'a pas inventé cette vulnérabilité structurelle. Elle l'a exploitée.

Le onze avril 2024 — deux semaines après la divulgation de Freund — la U.S. Cybersecurity and Infrastructure Security Agency a publié une déclaration officielle reconnaissant le problème structurel. Position de CISA : la charge de la sécurisation de l'infrastructure open-source ne peut pas incomber aux seuls mainteneurs bénévoles, et les entreprises consommant des logiciels open-source doivent y contribuer, soit financièrement, soit en temps de développement, pour produire un écosystème durable.

Les recommandations n'étaient pas contraignantes. Il s'agissait de bonnes pratiques. Elles dépendaient de l'adoption volontaire par des entreprises dont la structure d'incitation n'avait historiquement pas récompensé l'investissement.

En un mois, la Linux Foundation et l'Open Source Security Foundation ont publié une alerte conjointe avertissant que des tentatives de prise de contrôle par ingénierie sociale similaires étaient déjà en cours contre plusieurs autres projets open-source. L'OpenJS Foundation — qui maintient Node.js, jQuery et l'infrastructure JavaScript associée — a publiquement divulgué qu'elle avait reçu une campagne de pression coordonnée suivant le même modèle que xz-utils, et qu'elle l'avait repoussée uniquement parce que la divulgation de xz-utils avait appris à la communauté ce qu'il fallait rechercher.

Un rapport de la Linux Foundation de 2026 a documenté le modèle plus large à travers l'écosystème. La principale conclusion du rapport : ce qui s'est passé avec xz-utils n'était pas un incident singulier. C'était une méthode. La méthode est tentée à grande échelle. La plupart des détections réussies se produisent parce que le cas xz-utils a fourni une signature à laquelle comparer.

Combien de détections infructueuses il y a — des opérations déjà en cours qui n'ont pas encore été détectées — est par construction impossible à compter à partir de sources publiques.

Il y a deux épisodes sur Fragment Zero, le dossier sur l'hypothèse de la Dark Forest s'est clos sur une observation. La doctrine que Liu Cixin a formalisée en 2008 — le silence comme survie, la dissimulation comme nécessité stratégique, la révélation comme risque existentiel — est le plus ancien principe de sécurité opérationnelle dans l'histoire des conflits humains.

Toute force ayant opéré dans des conditions de menace incertaine et de capacité asymétrique est parvenue à la même conclusion.

Soyez silencieux. Avancez prudemment. Supposez l'observation.

L'opération xz-utils est la Dark Forest exécutée au sein d'une relation de confiance humaine.

L'attaquant n'a pas franchi un pare-feu. L'attaquant n'a pas exploité une zero-day. L'attaquant n'a pas contourné de protection cryptographique. L'attaquant a fait quelque chose de beaucoup plus simple. L'attaquant s'est caché à la vue de tous pendant trois ans, produisant un travail utile, bâtissant une crédibilité authentique, se comportant exactement comme tout autre contributeur utile, tout en préparant — silencieusement, patiemment, avec une patience stratégique inimaginable pour la plupart des organisations techniques — le moment où l'infrastructure préparée serait utilisée.

L'attaque a presque entièrement réussi parce qu'elle était silencieuse. Elle a été détectée non pas par un outil de sécurité, non pas par un audit, non pas par une défense institutionnelle, mais par l'observation accidentelle par un ingénieur de cinq cents millisecondes de latence inexpliquée.

La déclaration d'Andres Freund sur sa propre découverte, publiée sur Mastodon dans les semaines suivant la divulgation, devrait clore le dossier.

Compter sur la chance à l'avenir est une mauvaise stratégie.

La porte dérobée xz-utils a été découverte.

La version Dark Forest de l'opération — celle qui cible les relations de confiance plutôt que les systèmes informatiques — est tentée en ce moment même, contre un nombre indéterminé d'autres projets open-source critiques. Le modèle fonctionne. Les incitations économiques qui le font fonctionner n'ont pas fondamentalement changé. Les réponses institutionnelles ont été réelles mais insuffisantes.

L'ingénieur qui trouvera la prochaine aura également besoin de chance. Il devra regarder le bon benchmark au bon moment sur le bon système. Il devra s'intéresser suffisamment à tracer une anomalie jusqu'à sa source. Il devra publier ses découvertes avant que le commanditaire de l'opération n'ait déjà expédié la charge utile vers des versions stables.

Il aura besoin, spécifiquement, des cinq cents millisecondes.

Cet intervalle est ce qui se tenait entre Internet en mars 2024 et une seule clé cryptographique détenue par un acteur inconnu qui aurait déverrouillé chaque serveur Linux exécutant SSH sur Terre.

Fragment Zero suivra le dossier.

Le dossier ne se ferme pas. Il attend.