Compromission de serveurs SSH due à une porte dérobée présente dans le flux amont de xz/liblzma

• Plusieurs symptômes inhabituels liés à liblzma (qui fait partie du paquet xz) ont été observés sur une installation Debian sid : hausse de l’utilisation CPU lors des connexions SSH, erreurs valgrind
• La cause du problème a été identifiée : le dépôt amont et les tarballs de xz étaient infectés par une porte dérobée. Une partie de la porte dérobée n’existe que dans les tarballs distribués
• Le script inclus dans le tarball s’exécute à la fin de configure et, si certaines conditions sont remplies, modifie $builddir/src/liblzma/Makefile pour y injecter du code malveillant

Porte dérobée dans le dépôt

• La partie principale de la porte dérobée est présente sous forme chiffrée dans le répertoire tests/files du dépôt
• Ces fichiers n’étaient pas utilisés par les tests de la version 5.6.0, et dans la version 5.6.1 il y a eu une tentative de corriger les erreurs valgrind et les plantages causés par la porte dérobée

Systèmes affectés

• Le script de la porte dérobée est appelé pour la première fois après configure et ne modifie le processus de build que dans certaines conditions (par ex. systèmes Linux x86-64, utilisation de gcc et de l’éditeur de liens GNU, build de paquets Debian ou RPM)

Impact sur le serveur openssh

• Lorsqu’une version de liblzma avec la porte dérobée est installée, les connexions via SSH deviennent plus lentes
• openssh n’utilise pas directement liblzma, mais certaines distributions, dont Debian, appliquent des correctifs à openssh pour prendre en charge les notifications systemd, et libsystemd dépend de lzma

Analyse du code injecté

• L’analyse est faite du point de vue d’un observateur qui n’est ni chercheur en sécurité ni expert en rétro-ingénierie
• La porte dérobée intercepte l’exécution via un ifunc resolver et, pendant l’initialisation de sshd, résout les symboles afin de remplacer le symbole RSA_public_decrypt par son propre code

Impact sur sshd

• RSA_public_decrypt@....plt est modifié pour pointer vers le code de la porte dérobée, ce qui fait que ce code est appelé lors d’une authentification par clé publique
• Cela laisserait penser à un contournement de l’authentification ou à une exécution de code à distance

Signalement du bug

• Aucun bug n’a été signalé en raison de soupçons d’implication du dépôt amont
• Red Hat a attribué le CVE-2024-3094 à ce problème

Détection des installations vulnérables

• Un script est fourni pour détecter si le binaire ssh du système est vulnérable

[depth221]

Tout ce que je sais sur la porte dérobée de xz
Un article rédigé par Andres Freund, qui a découvert cette porte dérobée.

[edunga1]

C’est impressionnant de voir à quel point tout cela a été orchestré de manière méthodique ;; on dirait un scénario de série.

[carnoxen]

Même écartelé, ce ne serait pas volé.

[roxie]

Pourquoi ?

[keepworking]

Comme il s’agit d’un acte consistant à avoir intentionnellement implanté une porte dérobée dans l’open source… et qu’au cours du processus, il y a aussi eu des comportements comme mener discrètement une campagne d’influence sur l’opinion.
Il y a déjà eu auparavant des cas où des vulnérabilités ont été introduites de manière malveillante dans le noyau Linux, donc c’est assez amer.

[roxie]

Ah, je crois que je comprends enfin la nuance. Merci.

[GN⁺]

Avis Hacker News

• Liens associés :

  • Xz: Disable ifunc to fix Issue 60259
  • FAQ on the xz-utils backdoor
  • Everything I Know About the XZ Backdoor

• Résumé :

  • L’auteur de la backdoor a communiqué pendant plusieurs semaines pour tenter d’ajouter xz 5.6.x à Fedora 40 et 41. Il a collaboré pour résoudre les problèmes valgrind causés par cette backdoor, avant qu’il ne soit finalement établi que la backdoor était elle-même à l’origine du problème. Après une rupture accidentelle de l’embargo, il a fallu corriger la situation en urgence.
  • L’un des auteurs de la backdoor a lui-même désactivé dans oss-fuzz une fonctionnalité dépendant de la backdoor afin d’éviter sa découverte accidentelle.
  • L’auteur de la backdoor a ajouté un fichier SECURITY.md au projet xz-java. Ce fichier contient des consignes indiquant que les vulnérabilités de sécurité découvertes ne doivent pas être rendues publiques mais signalées en privé. Vu sous un autre angle, cela peut s’interpréter comme une tentative de gagner du temps pour ajuster son exploit et exploiter ses cibles.
  • openssh n’utilise pas directement liblzma, mais Debian et plusieurs distributions appliquent des patchs à openssh pour la prise en charge des notifications systemd. Cela fait que libsystemd dépend de liblzma, ajoutant ainsi une dépendance supplémentaire à des démons critiques pour la sécurité comme openssh et augmentant le risque d’attaque de la chaîne d’approvisionnement.
  • Points clés à vérifier pour les personnes en panique :
    • Si vous utilisez une version récente de liblzma5 (5.6.0 ou 5.6.1). Elle a été ajoutée au cours du dernier mois environ.
    • Si vous utilisez une distribution Linux basée sur Debian ou RPM. Cela semble être une tentative de rendre la rétro-ingénierie plus difficile.
    • Si vous exécutez OpenSSH sshd via systemd. Dans certaines distributions, OpenSSH patché utilise libsystemd pour les fonctionnalités de journalisation, ce qui entraîne l’inclusion de la version vulnérable de liblzma5.
    • Debian testing dispose déjà d’une version 5.6.1+really5.4.5-1, qui est en réalité l’ancienne version 5.4 reconditionnée comme une nouvelle version.
  • Si l’on voulait cacher quelque chose de suspect dans GNU autoconf, ce serait là qu’on le cacherait, plutôt que dans un script de type "curl | sh". Le responsable de cette diffusion s’occupait déjà des releases auparavant et a commencé à faire des commits en 2022. Il existe de nombreux commits contenant de vrais changements, ainsi que des contributions à des projets liés comme libarchive. Insérer cette backdoor a nécessité beaucoup d’efforts.
  • Il y a quelques années, quelqu’un a écrit une bibliothèque Go qui encapsule le code C de xz afin de permettre la compression xz depuis Go. Il a reçu il y a environ une semaine la première PR vers une mise à niveau en 5.6.1 sur ce dépôt. Elle provenait d’un compte GitHub différent de celui de l’amont.
  • Il apprécie que des contributeurs qui ne sont ni chercheurs en sécurité ni spécialistes de la rétro-ingénierie rédigent des articles techniques. Son rapport résumant sa découverte est considéré comme un excellent modèle pour les contributeurs en dehors du monde dominant du débogage, souvent réticents à partager leurs travaux.
  • En imaginant une tentative de backdoor plus habile sur xz(1), elle n’aurait probablement pas été découverte aussi rapidement. xz est utilisé presque partout. Il serait possible de créer une version de xz qui ne modifierait sélectivement que de petites portions de fichiers comme les tarballs logiciels .tar.xz servant de base à certains processus de build. La cible ne serait pas les tarballs du code source, mais ceux qui distribuent des binaires précompilés.