Ce que l’on sait de la porte dérobée de xz Utils qui a failli infecter presque le monde entier

Incident de la porte dérobée de xz Utils : ce que l’on sait d’un événement qui a failli infecter presque le monde entier

• xz Utils est un utilitaire de compression de données installé sur Linux ainsi que sur la quasi-totalité des systèmes d’exploitation de type Unix.
• Un incident a eu lieu dans lequel une mise à jour malveillante a failli y introduire une porte dérobée.
• Un développeur de Microsoft a découvert et rendu publique cette porte dérobée, évitant ainsi une crise juste avant son intégration dans de grandes distributions Linux comme Debian et Red Hat.

Comment la porte dérobée fonctionne-t-elle ?

• Le code malveillant ajouté dans les versions 5.6.0 et 5.6.1 manipule sshd, c’est-à-dire l’exécutable utilisé pour les connexions SSH.
• Une personne disposant d’une clé de chiffrement spécifique peut dissimuler du code dans un certificat d’authentification SSH, le téléverser et l’exécuter sur un appareil où la porte dérobée est installée.
• On ignore quel code a réellement été téléversé, mais en théorie diverses actions étaient possibles, comme le vol de clés de chiffrement ou l’installation de malware.

Comment la porte dérobée a été introduite

• La porte dérobée semble avoir été préparée sur plusieurs années.
• En 2021, un utilisateur nommé JiaT75 a contribué pour la première fois à un projet open source.
• En janvier 2023, JiaT75 apporte sa première contribution à xz Utils, puis assume progressivement davantage de responsabilités sous le nom de Jia Tan.
• Tan a remplacé dans le projet oss-fuzz les coordonnées de Collins par les siennes et a demandé la désactivation de la fonctionnalité ifunc pendant les tests.
• Ces changements ont empêché de détecter plus facilement les modifications malveillantes apportées par Tan à xz Utils.

Distributions touchées

• Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed et MicroOS, ainsi que Kali Linux incluaient des versions de xz contenant la porte dérobée.

L’avis de GN⁺

• Cet incident met en lumière les failles de sécurité de l’écosystème open source et contribue à renforcer la vigilance de la communauté des développeurs.
• Étant donné l’usage très répandu du logiciel concerné, cette affaire rappelle aux utilisateurs et administrateurs Linux l’importance de mettre à jour rapidement leurs systèmes et d’effectuer des vérifications de sécurité.
• Un cas similaire a été le piratage de SolarWinds, qui avait lui aussi montré les risques des attaques de la chaîne d’approvisionnement.
• Il est nécessaire de vérifier l’identité des développeurs qui contribuent aux projets open source et de renforcer les processus de revue de code.
• À la suite de cet incident, l’importance des audits de sécurité et des outils de détection de vulnérabilités devrait être encore davantage mise en avant.

[GN⁺]

Avis Hacker News

• OpenSSH est l’implémentation de sshd la plus populaire et n’est pas liée à la bibliothèque liblzma, mais Debian et beaucoup d’autres distributions Linux ajoutent un patch qui relie sshd à systemd. Or systemd est lié à liblzma, ce qui permettait à xz Utils d’affecter sshd.

• XZ est un programme de compression open source ainsi qu’une bibliothèque, utile pour écrire ses propres programmes manipulant des données compressées. Il est utilisé par de nombreux autres programmes, dont OpenSSH.

• Les binutils de GNU sont eux aussi liés à liblzma et sont encore plus largement utilisés qu’OpenSSH. Dans la plupart des cas, binutils servent à compiler OpenSSH, le système d’exploitation sur lequel sshd s’exécute, etc. Cela suggère que des acteurs malveillants ont choisi un projet idéal pour s’infiltrer en profondeur dans les logiciels open source.

• L’objectif est d’utiliser un framework de test standardisé qui aidera à écrire davantage de tests afin de soutenir la stabilité du projet XZ sur le long terme. Beaucoup de fonctionnalités ne sont pas encore testées, donc ces tests seraient utiles.

• Il y a eu peu de discussions sur le mécanisme de liaison permettant de s’accrocher à la fonction RSA_public_decrypt. Beaucoup d’échanges ont porté sur ce qu’on peut obtenir via la séparation de processus et autres techniques, mais peu sur cette redirection d’appel de fonction. La question est posée de savoir s’il serait possible de mettre en place un moyen de relier des composants critiques selon un modèle en couches de confiance.

• On parle d’une infection « presque » mondiale, mais en réalité des distributions Linux populaires comme Arch, Gentoo et openSUSE Tumbleweed ont diffusé pendant plusieurs semaines des versions contenant la porte dérobée, et sur Tumbleweed elle fonctionnait clairement. Le terme « presque » est inadapté.

• Prédiction qu’un cas similaire sera découvert dans les 12 prochains mois. Cela commencera par des mainteneurs qui se mettront à soupçonner les anciens commits des uns et des autres.

• Leçons personnelles tirées de cet incident :

  • Les archives tarball de distribution des sources qui contiennent du code différent du dépôt source sont une mauvaise chose. Il faut abandonner cette pratique.
  • Les artefacts générés automatiquement devraient toujours être commités.
  • Les artefacts générés automatiquement que tout le monde survole pendant les revues de code peuvent poser problème. Si ce type de fichiers existe dans le dépôt, il devrait y avoir des tests automatiques pour vérifier que personne ne les a altérés.
  • autotools et la culture autotools sont mauvaises.
  • libsystemd crée des problèmes dans l’écosystème. Les personnes qui critiquent systemd sont souvent ignorées, mais systemd est volumineux, complexe, avec beaucoup de dépendances, et la plupart des programmes n’en utilisent qu’une petite partie.
  • La culture selon laquelle la réutilisation de code est toujours bonne et qu’il est souhaitable de dépendre de grosses bibliothèques pour de petites fonctionnalités est erronée. Les dépendances apportent une charge de maintenance et des risques de sécurité, il faut donc équilibrer cela avec les fonctionnalités.
  • Le fait que les mainteneurs de distributions appliquent d’importants patches aux paquets peut poser problème. Cela crée des forks de fait largement utilisés sans personne pour réellement les maintenir.
  • Il faut permettre aux développeurs de pouvoir travailler financièrement sur l’OSS. liblzma et xz-utils sont installés sur des dizaines de millions de machines, mais ils reposent sur un seul mainteneur ayant des problèmes de santé mentale.
  • Les revues de code et le remplacement des mainteneurs doivent désormais prendre en compte les considérations géopolitiques actuelles.

• Expression de gratitude envers la personne qui a découvert le problème, un ingénieur Microsoft travaillant sur Azure Postgres. Cela donne désormais une meilleure image d’Azure.

• Le mainteneur historique de xz a transmis la responsabilité à Jia Tan, mais il est possible qu’il ne l’ait jamais rencontré ni même eu au téléphone. Questionnement sur le fait de ne communiquer que par e-mail/GitHub et sur le caractère habituel de cette pratique. On s’attend à ce que, après cette histoire, les mainteneurs de projets open source soient plus prudents.

• Même si l’on pense que cette porte dérobée a été découverte tôt, elle a peut-être déjà atteint son objectif. C’est d’autant plus vrai si les cibles étaient des développeurs utilisant des distributions en rolling release comme Kali et Debian.

• Cela suggère que l’affirmation selon laquelle Lasse Collin, mainteneur de longue date de xz Utils, ne mettait pas le logiciel à jour assez souvent ou assez vite était une erreur.