« Half a Second » : la backdoor XZ raconte enfin son histoire dans un livre

Le récit détaillé de l'attaque XZ Utils publié sous forme d'ouvrage. Retour sur l'incident qui a failli compromettre la majorité des serveurs Linux - et ce que le livre semble apporter.

Faits

Un livre intitulé « Half a Second », consacré à l'attaque contre XZ Utils, vient d'être annoncé (source : half-second.com, repérée sur Hacker News le 19 juillet 2026). Le titre fait référence au délai - une demi-seconde - qui a mis la puce à l'oreille de l'ingénieur Andres Freund et l'a poussé à investiguer une lenteur suspecte sur son environnement Debian.

Rappel du contexte. L'attaque XZ (référencée CVE-2024-3094) a été révélée fin mars 2024. Un contributeur au pseudonyme « Jia Tan » avait patiemment gagné la confiance de la communauté XZ Utils pendant près de deux ans, obtenu les droits de mainteneur, puis inséré une backdoor dans les versions 5.6.0 et 5.6.1 de la bibliothèque. Cette porte dérobée ciblait spécifiquement OpenSSH via une chaîne de dépendances subtile (systemd → libsystemd → liblzma) et aurait permis à un attaquant connaissant une clé privée d'exécuter du code arbitraire sur toute machine exposant un serveur SSH avec les versions vulnérables.

Ce que le livre semble apporter

À en croire la page de présentation, l'ouvrage retrace :

• Le travail de longue durée de l'attaquant (deux ans de contributions légitimes) pour asseoir sa réputation dans le projet.
• La pression psychologique exercée sur le mainteneur historique, Lasse Collin, notamment via des personas complices sur la mailing list qui réclamaient des releases plus rapides.
• La chronique de la détection par Andres Freund et la course contre la montre pour désamorcer avant intégration dans les distributions stables (Fedora Rawhide, Debian sid, openSUSE Tumbleweed étaient déjà touchées).

Analyse

L'affaire XZ reste, à ce jour, l'exemple le plus abouti d'attaque supply-chain contre le libre. Ce que le livre semble vouloir documenter - et c'est utile - c'est le côté social de l'attaque : la manipulation d'un mainteneur solo épuisé, la lente construction d'une confiance, l'usage de comptes fantômes pour presser la publication. Le code est presque secondaire.

Deux enseignements toujours d'actualité en 2026 :

1. Mainteneur solo = risque systémique. Tout projet libre stratégique doit avoir au moins deux mainteneurs actifs et un plan de succession clair. C'est ce que rappelle depuis longtemps l'OpenSSF (Open Source Security Foundation).
2. La détection est passée par un développeur curieux. Aucun outil automatisé n'a levé l'alerte : c'est un ingénieur (Freund travaille chez Microsoft sur PostgreSQL) qui a trouvé bizarre qu'un SSH mette 500 ms de plus à répondre. La culture d'observabilité paie.

À faire maintenant

• Vérifie que ton parc est bien à jour côté XZ Utils (patchs des distributions depuis avril 2024). C'est censé être fait, mais on continue de voir des machines mal patchées, notamment sur des rebuilds custom ou des VM figées.
• Pour tes propres projets libres : audite tes mainteneurs et tes dépendances critiques. Des outils comme deps.dev (Google) ou le programme Alpha-Omega de l'OpenSSF donnent une vue rapide de la santé d'une chaîne d'approvisionnement.
• Lis le livre quand il sortira : les études de cas comme celle-ci sont rares et précieuses pour former les équipes à repérer les patterns d'ingénierie sociale.