Compromission de XZ Utils (CVE-2024-3094)

CVE-2024-3094 touchait les tarballs XZ Utils 5.6.0/5.6.1. L’exposition dépendait du build de la distribution ; remplacez les paquets concernés.^{[1], [3], [4], [5], [6]}

Vecteur CVSS

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H^[9]

💡 Explication en Langage Simple (ELI5)

Imaginez une usine qui reçoit un kit de pièces scellé et assemble un produit. La recette publique paraît normale, mais un kit livré contient un composant caché supplémentaire. Une usine qui fabrique le kit à partir de la recette ne reçoit pas ce composant ; une usine qui emploie le kit scellé peut le recevoir. Un manifeste authentifié par un canal distinct peut détecter un kit remplacé, mais même une signature valide du fournisseur ne prouve pas qu’un kit autorisé est inoffensif : les kits XZ compromis étaient des versions officielles. Remplacez les paquets concernés selon les consignes de votre distribution ; utilisez la vérification du manifeste uniquement comme contrôle distinct contre la substitution.^{[5], [6]}

Concepts Clés et Termes

Tarball de publication: Archive distribuée pour une version logicielle. C’est une entrée de construction qui doit être vérifiée indépendamment de la source du dépôt qu’elle est censée représenter.^{[3], [4], [6]}
Provenance de construction: Éléments reliant un artefact construit à une source révisée, un processus de construction défini et une identité de publication fiable. La provenance rend détectable une divergence entre source et artefact.^{[5], [6]}
Vérification d’artefact: Contrôle d’un artefact de publication au moyen d’un manifeste signé fiable ou d’une empreinte reproduite indépendamment avant de l’admettre dans une construction ou un pipeline de paquets.

Correspondances de référentiels

Référence CWE pour la faiblesse décrite dans ce guide : CWE-506

Chronologie de l'Incident

24 février 2024

XZ Utils 5.6.0 a été publié ; la déclaration ultérieure du projet indique que son tarball de publication contenait une porte dérobée.^{[3], [6]}

9 mars 2024

XZ Utils 5.6.1 a été publié ; la même déclaration indique que son tarball de publication contenait une porte dérobée.^{[4], [6]}

Avant le 29 mars 2024

Freund a signalé un script de construction injecté dans des tarballs distribués, absent du fichier source upstream correspondant, après qu’une consommation CPU SSH inhabituelle et des erreurs Valgrind ont motivé l’enquête.^{[5], [6]}

29 mars 2024

Andres Freund a signalé publiquement le problème.^[5]

Déroulement de l'Attaque Étape par Étape

Étape 1

Un artefact de publication différait de la source attendue

Andres Freund a signalé qu’un script de construction injecté existait dans les tarballs distribués, mais pas dans le fichier source upstream correspondant. C’est un défaut de provenance : la révision d’une entrée ne prouvait pas l’identité de l’autre.^{[5], [6]}

Étape 2

Les conditions de construction et de distribution comptaient

Les rapports décrivent des données tirées de fichiers de test .xz pendant la construction des tarballs touchés. Freund a aussi indiqué qu’une construction depuis Git n’injecterait pas le code et que le chemin de dépendance dépendait des choix de construction de la distribution.^{[5], [6]}

Étape 3

Un comportement anormal a déclenché l’enquête

Freund a signalé une consommation CPU SSH inhabituelle et des erreurs Valgrind. Ces symptômes ont conduit à examiner l’artefact de publication et son comportement de construction plutôt qu’à accepter une régression de performance inexpliquée.^[5]

Étape 4

Le confinement commence par le remplacement et la vérification des paquets

Traitez le cas comme un incident touchant des paquets et leur provenance de construction. Suivez les consignes de votre distribution et remplacez les paquets concernés. Pour les futurs artefacts, vérifiez leur provenance et leurs signatures : cela peut détecter une substitution, mais pas établir qu’une version autorisée est inoffensive.^{[1], [6]}

Code Source : Vulnérable vs Sécurisé

IMPLÉMENTATION VULNÉRABLE

# Accepte une entrée de construction téléchargée sans prouver son identité.
from pathlib import Path

def stage_release(artifact: Path, build_inputs: Path) -> None:
    build_inputs.joinpath(artifact.name).write_bytes(artifact.read_bytes())

# Une copie réussie ne prouve pas que cette archive correspond
# à la publication révisée ou à un manifeste fiable de l’éditeur.

PATCH SÉCURISÉ ET ROBUSTE

# Porte illustrative : vérifie un SHA-256 attendu issu d’un manifeste fiable.
import hashlib
import hmac
from pathlib import Path

def verify_release(artifact: Path, expected_sha256: str) -> None:
    digest = hashlib.sha256(artifact.read_bytes()).hexdigest()
    if not hmac.compare_digest(digest, expected_sha256.lower()):
        raise ValueError("l’artefact de publication ne correspond pas au manifeste fiable")

# Obtenez expected_sha256 par un processus de publication authentifié séparément
# puis appelez verify_release avant que l’archive devienne une entrée de construction.

# Cela détecte une substitution, pas une version autorisée mais malveillante ; suivez les consignes pour les paquets concernés.

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Suivez les consignes de votre distribution pour CVE-2024-3094, identifiez et remplacez les paquets et versions réellement touchés, puis vérifiez la provenance du paquet de remplacement.^{[1], [6]}
✓Avant qu’une archive de publication ne devienne une entrée de construction, comparez-la à une empreinte ou une signature obtenue par un canal authentifié séparément ; échouez de façon sûre en cas d’écart, car un téléchargement réussi ne prouve pas la provenance.
✓Pour les constructions reproductibles, consignez la révision source, l’environnement de construction, l’empreinte de l’artefact, l’identité du constructeur et la configuration ; comparez des constructions indépendantes lors de la mise à jour de dépendances critiques.
✓Examinez les archives de publication, scripts de construction, règles de paquetage et artefacts de test avec autant de rigueur que le code applicatif ; consignez l’origine et l’intégrité des données binaires de test inexpliquées.^{[5], [6]}
✓Exigez l’approbation d’au moins deux responsables pour les changements d’outils de publication, de configuration CI et d’étapes de paquetage, séparément de l’approbation du code applicatif courant ; conservez des traces vérifiables.
✓Enquêtez sur toute utilisation CPU inexpliquée lors de constructions ou en service, les régressions de performance et les erreurs mémoire ou d’outils de validation ; conservez artefacts et preuves pour comparaison.^[5]