> ## 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.

# Backdoor dans xz-utils (CVE-2024-3094) : un cas d'école d'attaque sur la supply chain

> Une porte dérobée délibérément introduite dans xz-utils 5.6.0 et 5.6.1 visait OpenSSH via systemd. Détection précoce, périmètre limité — mais leçon majeure.

*Publié le 2 avril 2024*

<Warning>
  **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.
</Warning>

## 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 :

```bash theme={null}
xz --version
```

Si la sortie affiche **5.6.0** ou **5.6.1**, vous êtes potentiellement exposé.

```bash theme={null}
# 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 :

```bash theme={null}
sudo pacman -Syyuu  # mise à jour complète
```

Sur Debian unstable/testing :

```bash theme={null}
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](https://onetsolutions.net).