# CVE-2024-3094 : XZ Utils Backdoor : la supply chain qui a fait trembler tout Linux

> Une porte dérobée sophistiquée placée dans la bibliothèque xz-utils (liblzma), découverte par hasard par un ingénieur Microsoft à cause d'une latence anormale sur SSH. Patient zéro d'une nouvelle ère de la supply chain offensive.

- Page canonique : https://kreomnisvigie.com/cve/cve-2024-3094-xz-utils
- Sévérité : Critique · CVSS 10.0 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
- EPSS : 95 % de probabilité d'exploitation à 30 jours
- CISA KEV (exploitation observée) : oui
- Produits : xz-utils 5.6.0 ; xz-utils 5.6.1
- Correctif disponible : oui · PoC public : oui · Exploitée : oui
- Publiée le 29 mars 2024 · mise à jour le 15 avril 2024 · Kreomnis
- Mots clés : supply-chain, linux, ssh, liblzma, backdoor

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

```bash
# 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`](https://github.com/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

## Références

- [Annonce initiale (oss-security)](https://www.openwall.com/lists/oss-security/2024/03/29/4) (openwall)
- [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) (cisa)
- [Avis CERT-FR (CERTFR-2024-AVI-0274)](https://www.cert.ssi.gouv.fr/) (cert-fr)

Source : Kreomnis Vigie, https://kreomnisvigie.com/cve/cve-2024-3094-xz-utils. Analyse à usage défensif uniquement.