Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt

Use this file to discover all available pages before exploring further.

Publié le 2 avril 2024
CVE-2024-3094. Une backdoor a été délibérément introduite dans les versions 5.6.0 et 5.6.1 de la bibliothèque xz-utils. Détectée le 29 mars 2024 par un développeur Postgres curieux qui enquêtait sur des temps de connexion SSH anormaux, l’attaque a été stoppée avant d’atteindre les distributions stables. Mais elle aurait pu — et c’est ça, l’histoire.

​
Ce qui s’est passé

Pendant deux ans, un contributeur sous le pseudonyme Jia Tan a gagné la confiance de la communauté xz-utils, jusqu’à devenir co-mainteneur du projet. Avec ce statut, il a injecté progressivement, à travers plusieurs commits éparpillés, un payload obfusqué dans la bibliothèque liblzma. Au build, le payload :
  1. Détecte qu’il est compilé dans un contexte qui sera ensuite chargé par sshd via systemd (les distributions qui patchent sshd pour le rendre dépendant de libsystemd, qui dépend de liblzma).
  2. Hooke certaines fonctions internes de sshd au démarrage.
  3. Permet à un opérateur en possession d’une clé spécifique de bypasser l’authentification SSH avec n’importe quel utilisateur, sans laisser de trace dans les logs.
C’est-à-dire : un accès root universel sur des dizaines de millions de serveurs, à travers une porte dérobée qui n’aurait pas été détectable par les outils classiques.

​
Pourquoi ça n’a pas été un désastre planétaire

Andres Freund, mainteneur Postgres chez Microsoft, débuggait des temps de connexion SSH suspects de l’ordre de 500 ms. En remontant la chaîne, il a fini par trouver le payload — et a alerté oss-security le 29 mars 2024. À ce moment-là, les versions 5.6.0 et 5.6.1 n’étaient présentes que dans :
  • Fedora 41 et Rawhide
  • Debian testing/unstable/experimental
  • openSUSE Tumbleweed, openSUSE MicroOS
  • Arch Linux
  • Quelques canaux bleeding edge de macOS via Homebrew
Aucune distribution stable de production n’embarquait ces versions. Le périmètre réel de compromission était donc minime.

​
Êtes-vous concerné ?

Vérifiez la version de xz installée : 
xz --version
Si la sortie affiche 5.6.0 ou 5.6.1, vous êtes potentiellement exposé. 
# Sur Debian/Ubuntu
dpkg -l xz-utils liblzma5

# Sur Fedora/RHEL/AlmaLinux/Rocky
rpm -qa | grep -i xz

# Sur Arch
pacman -Q xz

​
Que faire

​
Si vous êtes sur une version 5.6.x

Downgradez vers 5.4.x (la dernière version saine) immédiatement. Toutes les distributions concernées ont publié des paquets fixés depuis. Sur Arch : 
sudo pacman -Syyuu  # mise à jour complète
Sur Debian unstable/testing : 
sudo apt update && sudo apt install --reinstall xz-utils liblzma5

​
Si vous êtes sur une distribution stable

Vous n’êtes pas concerné. La 5.6.0/5.6.1 n’a jamais atteint Debian stable, Ubuntu LTS, RHEL stable, etc.

​
Quel que soit votre cas

Profitez de l’épisode pour reposer la question : quels paquets compilez-vous depuis source ou installez-vous depuis des dépôts non officiels ? L’attaque xz-utils a révélé la fragilité d’un modèle où un mainteneur unique d’une lib critique peut compromettre la planète. Ça appelle :
  • Une réduction stricte des dépendances buildées en interne.
  • L’utilisation de mirrors signés et auditables.
  • Une revue plus serrée des dépendances transitives critiques (libs cryptographiques, libs de compression, drivers, etc.).

​
Ce qu’il faut retenir

xz-utils n’est pas une “vulnérabilité” classique : c’est une attaque sur la supply chain open source, avec ingénierie sociale longue (deux ans de travail) et payload technique sophistiqué. La leçon pratique : mettre à jour vers une version saine. La leçon stratégique : la confiance dans le code open source ne se résume pas à “c’est public”. Auditez ce que vous embarquez. Pour toute question, ouvrez un ticket depuis votre espace client OnetSolutions.