Des chercheurs ont découvert une porte dérobée malveillante dans un outil de compression qui s’est infiltré dans des distributions Linux largement utilisées, notamment celles de Red Hat et Debian. L’utilitaire de compression, connu sous le nom de xz Utils, a introduit le code malveillant dans ses versions 5.6.0 et 5.6.1 selon Andres Freund, le développeur qui l'a découverte.Aucun rapport connu ne fait état de l'intégration de ces versions dans les versions de production des principales distributions Linux, mais Red Hat et Debian ont signalé que les versions bêta publiées récemment utilisaient au moins l'une des versions rétroactives, en particulier dans les distributions Fedora Rawhide et Debian testing, unstable et experimental. Une version stable d'Arch Linux est également concernée. Cette distribution n'est toutefois pas utilisée dans les systèmes de production.
La porte dérobée ayant été découverte avant que les versions malveillantes de xz Utils ne soient ajoutées aux versions de production de Linux, « elle n'affecte personne dans le monde réel », a déclaré Will Dormann, analyste principal des vulnérabilités au sein de la société de sécurité Analygence. « Mais c'est uniquement parce qu'elle a été découverte rapidement en raison de la négligence d'un acteur malveillant. Si elle n'avait pas été découverte, elle aurait été catastrophique pour le monde entier ».
Introduction de la porte dérobée
Le 23 février, une mise à jour a ajouté du code obfusqué, et le jour suivant, un script d’installation malveillant s’est injecté dans les fonctions utilisées par sshd, le fichier binaire qui permet le fonctionnement de SSH. Le code malveillant n’a été présent que dans les versions archivées (connues sous le nom de tarballs), qui sont publiées en amont. Le code GIT disponible dans les référentiels n’est pas affecté, bien qu’il contienne des artefacts de deuxième étape permettant l’injection lors de la construction. Si le code obfusqué introduit le 23 février est présent, les artefacts dans la version GIT permettent à la porte dérobée de fonctionner.
Les modifications malveillantes ont été soumises par JiaT75, l’un des deux principaux développeurs de xz Utils avec des années de contributions au projet. Andres Freund, le développeur qui a découvert la porte dérobée, a noté que compte tenu de l’activité sur plusieurs semaines, le contributeur est soit directement impliqué, soit son système a été compromis de manière assez sévère. « Malheureusement, cette dernière explication semble la moins probable, étant donné qu'il a communiqué sur diverses listes à propos des "correctifs" fournis dans les récentes mises à jour », a-t-il continué.
Jeudi, une personne utilisant le nom du développeur s'est rendue sur un site de développeurs pour Ubuntu afin de demander que la version 5.6.1 antidatée soit incorporée dans les versions de production, car elle corrigeait des bogues qui provoquaient le dysfonctionnement d'un outil connu sous le nom de Valgrind.
« Cela pourrait perturber les scripts de construction et les pipelines de test qui attendent des résultats spécifiques de Valgrind pour réussir », a averti la personne, à partir d'un compte créé le même jour.
L'un des responsables de Fedora a déclaré vendredi que le même développeur l'avait approché ces dernières semaines pour demander que Fedora 40, une version bêta, incorpore l'une des versions d'utilitaires rétroactives.
« Nous avons même travaillé avec lui pour résoudre le problème de valgrind (qui s'est avéré être causé par la porte dérobée qu'il avait ajoutée) », a déclaré le responsable d'Ubuntu. « Il fait partie du projet xz depuis deux ans, ajoutant toutes sortes de fichiers de test binaires, et avec ce niveau de sophistication, nous nous méfierions des versions plus anciennes de xz jusqu'à preuve du contraire ».
Selon les chercheurs, les versions malveillantes interfèrent intentionnellement avec l'authentification effectuée par SSH, un protocole couramment utilisé pour se connecter à distance à des systèmes. SSH fournit un chiffrement robuste pour garantir que seules les parties autorisées se connectent à un système distant. La porte dérobée est conçue pour permettre à un acteur malveillant de briser l'authentification et, à partir de là, d'obtenir un accès non autorisé à l'ensemble du système. La porte dérobée fonctionne en injectant du code pendant une phase clé du processus de connexion.
« Je n'ai pas encore analysé précisément ce qui est vérifié dans le code injecté pour permettre un accès non autorisé », a écrit Freund. « Étant donné que ce code est exécuté dans un contexte de préauthentification, il semble probable qu'il permette une forme d'accès ou une autre forme d'exécution de code à distance ».
Dans certains cas, la porte dérobée n'a pas pu fonctionner comme prévu. L'environnement de build de Fedora 40, par exemple, contient des incompatibilités qui empêchent l'injection de se produire correctement. Fedora 40 est maintenant revenue aux versions 5.4.x de xz Utils.
Xz Utils est disponible pour la plupart des distributions Linux, mais toutes ne l'incluent pas par défaut. Toute personne utilisant Linux doit immédiatement vérifier auprès de son distributeur si son système est affecté. Freund a fourni un script permettant de détecter si un système SSH est vulnérable.
Plusieurs personnes ont signalé que les applications incluses dans le gestionnaire de paquets HomeBrew pour macOS utilisaient la version 5.6.1 de xz Utils avec la porte dérobée. HomeBrew a depuis rétrogradé l’utilitaire à la version 5.4.6.
Les distributions affectées
Red Hat a averti vendredi qu'une porte dérobée malveillante découverte dans la bibliothèque logicielle de compression de données xz, largement utilisée, pourrait être présente dans des instances de Fedora Linux 40 et dans Fedora Rawhide, une version de Fedora en perpétuel développement (cette version sert à l'inclusion de technologies émergentes ayant un avenir dans les versions futures et stables de Fedora. Rawhide n'est jamais stable. Deux fois par an, un état « x » de Rawhide est copié en une nouvelle branche parallèle, qui sera quant à elle stabilisée et débogué pour devenir une version stable de Fedora). La grande enseigne de l'informatique a déclaré que le code malveillant, qui semble fournir un accès à distance via OpenSSH et systemd au moins, est présent dans xz 5.6.0 et 5.6.1. La vulnérabilité a été désignée sous le nom de CVE-2024-3094. Elle est notée 10 sur 10 dans la sévérité CVSS.
Les utilisateurs de Fedora Linux 40 peuvent avoir reçu la version 5.6.0, en fonction de la date de mise à jour de leur système, selon Red Hat. Les utilisateurs de Fedora Rawhide, la version de développement actuelle de ce qui deviendra Fedora Linux 41, pourraient avoir reçu la version 5.6.1. Les versions 40 et 41 de Fedora n'ont pas encore été officiellement publiées ; la version 40 devrait sortir le mois prochain.
Les utilisateurs d'autres distributions Linux et OS doivent vérifier quelle version de la suite xz ils ont installée. Les versions infectées, 5.6.0 et 5.6.1, ont été publiées respectivement le 24 février et le 9 mars, et n'ont peut-être pas été intégrées dans les déploiements de beaucoup de personnes.
Cette compromission de la chaîne d'approvisionnement a peut-être été détectée suffisamment tôt pour empêcher une exploitation généralisée, et elle n'affecte peut-être que les distros de pointe qui ont immédiatement récupéré les dernières versions de xz.
Debian Unstable et Kali Linux ont indiqué qu'elles étaient, comme Fedora, affectées ; tous les utilisateurs devraient prendre des mesures pour identifier et supprimer toutes les versions de xz ayant fait l'objet d'une rétrocession.
« Veuillez cesser immédiatement d'utiliser toute instance de Fedora Rawhide pour votre travail ou vos activités personnelles », a déclaré la filiale d'IBM. « Fedora Rawhide sera prochainement ramené à la version xz-5.4.x. Une fois cette opération effectuée, les instances Fedora Rawhide pourront être redéployées en toute sécurité ».
Red Hat Enterprise Linux (RHEL) n'est pas concerné.
SUSE a publié un correctif pour les utilisateurs d'openSUSE.
Le code malveillant dans les versions 5.6.0 et 5.6.1 de xz a été obscurci, selon Red Hat, et n'est présent que dans l'archive du code source. Les artefacts de seconde étape dans le repo Git sont transformés en code malveillant par le biais de la macro M4 dans le repo pendant le processus de construction. La bibliothèque xz empoisonnée qui en résulte est utilisée à son insu par des logiciels, tels que le système d'exploitation systemd, une fois que la bibliothèque a été distribuée et installée. Le logiciel malveillant semble avoir été conçu pour altérer le fonctionnement des démons du serveur OpenSSH qui utilisent la bibliothèque via systemd.
« La version malveillante qui en résulte interfère avec l'authentification dans sshd via systemd », explique Red Hat. « SSH est un protocole couramment utilisé pour se connecter à distance à des systèmes, et sshd est le service qui permet l'accès ».
Conclusion
Cette interférence d'authentification peut permettre à un malfaiteur de rompre l'authentification sshd et d'obtenir à distance un accès non autorisé à un système affecté. En résumé, la porte dérobée semble fonctionner comme suit : Les machines Linux installent la librairie xz - plus précisément, liblzma - et cette dépendance est finalement utilisée d'une manière ou d'une autre par le daemon OpenSSH de l'ordinateur. À ce stade, la bibliothèque xz empoisonnée est en mesure d'interférer avec le démon et de permettre à un malfaiteur non autorisé de se connecter à distance.
Cette découverte souligne l’importance de la sécurité dans la chaîne d’approvisionnement logicielle et met en évidence les risques potentiels pour les systèmes SSH. Il est essentiel de surveiller de près les mises à jour et de vérifier l’intégrité des outils et des bibliothèques utilisés dans les distributions Linux et autres systèmes d’exploitation.
Sources : Andres Freund, HomeBrew, Ubuntu, Red Hat CVE-2024-3094, avis de sécurité de Red Hat, SUSE, Debian
Et vous ?
Quelle est votre opinion sur la sécurité dans la chaîne d’approvisionnement logicielle ? Pensez-vous que les développeurs et les mainteneurs de logiciels devraient être plus vigilants lorsqu’ils intègrent des mises à jour ou des bibliothèques tierces ? Comment cela pourrait-il affecter la confiance des utilisateurs envers les distributions Linux et les outils open source ? La découverte de cette porte dérobée pourrait-elle entraîner une méfiance accrue envers les logiciels open source ? Comment les projets open source peuvent-ils renforcer la confiance des utilisateurs ? Quelles mesures de sécurité supplémentaires devraient être mises en place pour détecter et prévenir de telles menaces ? Comment pouvons-nous améliorer la détection précoce des portes dérobées et des vulnérabilités dans les logiciels largement utilisés ? Quel rôle les entreprises et les organisations jouent-elles dans la vérification de la sécurité des logiciels qu’elles utilisent ? Devraient-elles investir davantage dans des audits de sécurité indépendants pour s’assurer que les outils qu’elles utilisent sont exempts de portes dérobées ? Comment pouvons-nous sensibiliser davantage les utilisateurs et les développeurs à l’importance de la sécurité logicielle ? Quelles initiatives éducatives ou de sensibilisation pourraient aider à prévenir de telles situations à l’avenir ? 
Envoyé par Stéphane le calme
