XZ Utils Backdoor : la supply chain qui a fait trembler tout Linux

Le contexte

Le 29 mars 2024, Andres Freund - ingénieur Microsoft, mainteneur PostgreSQL - publie un message sur la mailing-list oss-security qui va changer la perception de la sécurité open source : il a découvert, par hasard, une porte dérobée volontairement introduite dans xz-utils (paquet liblzma), affectant les versions 5.6.0 et 5.6.1.

Le déclencheur ? Une augmentation de 500 ms de la latence des connexions SSH sur sa machine Debian sid. Un ingénieur curieux, un profil obstiné - sans lui, le backdoor entrait dans Debian stable, Ubuntu LTS, RHEL.

Ce que fait la backdoor

La charge utile, dissimulée dans des fichiers de test binaires censés être inoffensifs, modifie le résolveur de fonctions GNU IFUNC au chargement de liblzma. À l'exécution, elle hooke la fonction RSA_public_decrypt d'OpenSSL via sshd (qui charge liblzma indirectement via systemd-notify sur les distributions concernées).

Conséquence :

• Un attaquant disposant de la clé privée correspondante peut envoyer une signature RSA forgée durant la phase de handshake SSH.
• Si la signature passe le contrôle (qui est trafiqué), sshd exécute la charge utile comme code arbitraire, en root, sans authentification.

Autrement dit : RCE root pré-authentification, à distance, sur des millions de serveurs Linux. CVSS 10.0 - pas une exagération.

Comment l'a-t-on glissée ?

C'est la partie la plus inquiétante :

1. Patient infiltration - depuis ~2021, un contributeur sous le pseudonyme Jia Tan (jiat75) prend progressivement la confiance de Lasse Collin, mainteneur historique d'xz.
2. Captation - des comptes-fantômes ("Jigar Kumar", "Dennis Ens") ont publiquement fait pression sur Lasse pour qu'il transfère le projet à Jia Tan. Lasse, en burnout, finit par accepter de partager les commits.
3. Déploiement - fin février 2024, les versions 5.6.0 puis 5.6.1 sortent avec la charge utile encodée dans tests/files/bad-3-corrupt_lzma2.xz et déballée à la volée par un build-to-host.m4 malicieux.

Ce n'est pas un bug. C'est une opération sponsorisée, vraisemblablement étatique, qui a duré au moins trois ans.

Vérifier si vous êtes vulnérable

# Version installée du paquet
xz --version

# Plus précis (sur Debian/Ubuntu) :
dpkg -l | grep -E "xz-utils|liblzma"

# Sur RHEL/Rocky/Alma :
rpm -qa | grep -E "xz|liblzma"

Si la version commence par 5.6.0 ou 5.6.1 → vulnérable. Toute autre version (5.4.x, 5.6.2+) → sûre.

Détection plus robuste : le script communautaire de Vegard Nossum, qui examine la binary signature de liblzma.

Comment patcher

| Distribution | Action | | --- | --- | | Debian sid / testing | apt update && apt install xz-utils (rétrogradage en 5.4.5+) | | Fedora Rawhide / 40 beta | dnf downgrade xz ; les images Rawhide affectées ont été retirées | | openSUSE Tumbleweed | mise à jour zypper standard | | Ubuntu | aucune version stable n'a embarqué 5.6.x ; vérifier noble (24.04) avant release | | Alpine | 5.6.1-r1 revient en 5.4.6 | | Arch | mise à jour standard ; pacman -Syu |

Pas de redémarrage suffisant : il faut s'assurer que tout processus sshd est rechargé avec le nouveau liblzma. En pratique : systemctl restart sshd.

PoC publics

Plusieurs équipes ont reconstitué la chaîne d'exploitation :

• Le repo amlweems/xzbot fournit un client SSH modifié qui démontre la RCE quand la clé privée de l'attaquant est connue (la vraie clé n'est pas publique).
• Une analyse complète, étape par étape, du backdoor est maintenue par Russ Cox.

⚠️ La clé privée nécessaire à l'exploitation n'est pas publique. L'exploit "Internet-wide" suppose que vous êtes l'attaquant d'origine. Mais comme la fenêtre d'opportunité a duré ~5 semaines, on ne peut pas exclure une exploitation discrète durant cette période.

Ce qu'il faut retenir

Un projet open source critique tenait sur un mainteneur en burnout. Trois ans de patience, et la moitié de l'Internet exposée.

Pour les RSSI et les équipes DevSecOps :

• Inventoriez les dépendances natives, pas seulement npm/PyPI.

• Suivez les changements de mainteneur dans les projets critiques.

• Diversifiez : ne pas dépendre d'un seul binaire pour des fonctions de sécurité (ex. SSH).

• Auditez ce qui finit dans init / systemd - c'est la chaîne la plus exposée.

• Kreomnis