Affaire xz : un coup de chance, et le pire scénario supply chain évité

Ce qui s'est passé

Un mainteneur du paquet xz-utils, sous le pseudonyme Jia Tan, a passé environ trois ans à gagner la confiance du mainteneur historique Lasse Collin. En février 2024, il a injecté dans les versions 5.6.0 et 5.6.1 une porte dérobée capable d'exécuter du code arbitraire root via SSH, sans authentification.

Le 29 mars, Andres Freund (ingénieur Microsoft, mainteneur PostgreSQL) a publié sur oss-security la découverte qu'il avait faite par hasard, parce qu'une connexion SSH lui semblait prendre 500 ms de trop. Sans lui, le backdoor entrait dans Debian stable, Ubuntu LTS, RHEL.

Notre analyse technique complète de CVE-2024-3094.

Ce que Kreomnis en pense

Ce n'était pas une faille. C'était une opération.

Trois leçons qu'on évoque rarement :

1. Le burn-out des mainteneurs est un risque de sécurité nationale

Lasse Collin maintenait xz-utils quasi seul, en open source, gratuitement, depuis plus de quinze ans. Il a fini par accepter de partager les commits à Jia Tan parce qu'il n'en pouvait plus. Ceux qui ont mis la pression pour qu'il transfère le projet (les comptes-fantômes Jigar Kumar, Dennis Ens) savaient exactement ce qu'ils faisaient.

Tant que les briques critiques de l'Internet reposeront sur des mainteneurs uniques, payés zéro, nous serons à un burn-out près de la prochaine compromission. Ce n'est pas un problème open source. C'est un problème d'infrastructure publique sous-financée.

2. La vélocité des distributions amont est un facteur de risque

La porte dérobée a été détectée parce que xz 5.6.x était encore en bêta sur Fedora Rawhide et Debian sid. Si l'attaquant avait été plus patient - disons six mois de plus - la version serait entrée en stable. La détection aurait été massivement plus difficile.

Le côté positif : les distributions stables (Ubuntu LTS, RHEL, Debian stable) ont fait leur travail de filtre temporel. Le côté négatif : les utilisateurs de rolling releases (Arch, openSUSE Tumbleweed, Fedora) sont en première ligne.

3. Vos audits SBOM ne servent à rien si vous ne suivez pas les changements de mainteneurs

L'industrie a passé deux ans à pousser le concept de SBOM (Software Bill of Materials) - savoir ce qu'il y a dans votre logiciel. C'est nécessaire mais pas suffisant.

Ce qui a fait basculer xz, ce n'est pas un changement de dépendance. C'est un changement de mainteneur, sur une dépendance qui était dans tous les SBOM depuis quinze ans. Tant qu'on n'a pas de système qui alerte sur les transferts de gouvernance des projets critiques (qui commit ? depuis quand ? qui a écrit le dernier release blob ?), on reste aveugle.

À surveiller dans les prochains mois

• D'autres backdoors du même opérateur : on a trouvé un projet, on n'a pas trouvé l'opérateur.
• Les conférences post-mortem : la BSides Las Vegas et la DEF CON 32 ont eu plusieurs talks majeurs sur le sujet. Worth your time.
• Les propositions de réglementation : NIS2, CRA (Cyber Resilience Act) vont presque certainement intégrer des obligations spécifiques aux briques open source critiques.

Cet article est un commentaire éditorial de Kreomnis. Pour les faits bruts, consultez l'annonce originale d'Andres Freund.