La faille XZ Utils dans Linux met en évidence un problème de sécurité plus large dans la chaîne d'approvisionnement, et il nous faudra plus qu'un esprit communautaire pour le maîtriser.

Suite à la découverte d'une faille insidieuse dans la chaîne logistique des logiciels, le secteur de la cybersécurité a de nouveau été placé en état d'alerte maximale. La faille de sécurité, qui affecte la bibliothèque de compression de données XZ Utils incluse dans les principales distributions Linux, est répertoriée sous le numéro CVE-2024-3094 et consiste en une porte dérobée délibérément introduite par un administrateur système bénévole autrefois considéré comme fiable. Dans certains cas, elle permet l'exécution de code à distance (RCE) lorsqu'elle est exploitée avec succès et constitue un problème grave qui peut causer de sérieux dommages dans les processus de compilation de logiciels établis.

Heureusement, un autre administrateur a découvert cette menace avant que le code malveillant ne se retrouve dans les versions stables de Linux, mais elle reste un problème pour ceux qui ont commencé à utiliser les versions 5.6.0 et 5.6.1 de XZ Utils dans le cadre de Fedora Rawhide, et les organisations sont invitées à appliquer le correctif en priorité. Si cette découverte n'avait pas été faite à temps, il s'agirait de l'une des attaques de chaîne d'approvisionnement les plus dévastatrices de tous les temps en raison de son profil de risque, surpassant peut-être même SolarWinds.

La dépendance à l'égard des bénévoles de la communauté pour la maintenance des systèmes critiques est largement documentée, mais rarement discutée jusqu'à ce que des problèmes graves tels que cet incident apparaissent. Bien que leur travail inlassable soit essentiel à la maintenance des logiciels open source, cela souligne la nécessité d'accorder une grande importance aux compétences et à la sensibilisation en matière de sécurité au niveau des développeurs, sans oublier le renforcement des contrôles d'accès autour des référentiels logiciels.

Qu'est-ce que la porte dérobée XZ Utils et comment peut-on la désactiver ?

Le 29 mars, Red Hat a publié une alerte de sécurité urgente pour informer les utilisateurs de Fedora Linux 4.0 et Fedora Rawhide que les dernières versions des outils et bibliothèques de compression « XZ » contiennent du code malveillant qui semble avoir été spécialement conçu pour faciliter l'accès non autorisé par des tiers. La manière dont ce code malveillant a été introduit fera probablement l'objet d'études approfondies à l'avenir, mais il s'agit d'un exercice d'ingénierie sociale sophistiqué, patient et de longue haleine de la part de l'auteur de la menace, un attaquant pseudonyme nommé « Jia Tan ». Cette personne a passé d'innombrables heures à gagner la confiance d'autres contributeurs, a apporté des contributions légitimes au projet XZ Utils et à la communauté pendant plus de deux ans, et a finalement obtenu le statut de « contributeur de confiance » après que plusieurs comptes fictifs aient sapé la confiance dans le propriétaire bénévole du projet, Lasse Collin :

‍

‍

Ce scénario inhabituel illustre parfaitement qu'une personne hautement qualifiée sur le plan technique peut toujours être victime de tactiques généralement utilisées contre des personnes moins expérimentées, et montre qu'une formation précise et adaptée au poste occupé est nécessaire pour sensibiliser à la sécurité. C'est uniquement grâce à la curiosité et à la vivacité d'esprit de l'ingénieur logiciel Microsoft et du responsable PostgreSQL que la faille a été découverte et les versions réinitialisées, ce qui a permis de mettre fin à ce qui pourrait être l'attaque de chaîne d'approvisionnement la plus dévastatrice de ces derniers temps. Andres Freund a permis de découvrir la porte dérobée et de réinitialiser les versions, mettant ainsi fin à ce qui aurait pu être l'attaque de la chaîne d'approvisionnement la plus dévastatrice de ces derniers temps.

La porte dérobée elle-même est officiellement classée comme une faille de sécurité présentant le niveau de gravité le plus élevé dans le registre du NIST. À l'origine, on pensait qu'elle permettait de contourner l'authentification SSH, mais des recherches plus approfondies ont révélé qu'elle permettait l'exécution de code à distance non authentifié sur les systèmes Linux vulnérables, notamment Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed et certaines versions de Debian.

Jia Tan semble avoir déployé des efforts considérables pour dissimuler le paquet malveillant. Lorsqu'il est amené à se créer lui-même pendant le processus de compilation, il perturbe l'authentification dans SSHD via systemd. Comme le détaille Red Hat, dans certaines circonstances, cette perturbation pourrait permettre à un attaquant de contourner l'authentification SSHD et d'obtenir un accès à distance non autorisé à l'ensemble du système.

Microsoft a notamment publié des directives complètes sur la recherche de cas d'exploitation dans les systèmes et sur l'atténuation de leurs effets. La mesure d'urgence recommandée par la CISA est que les développeurs et les utilisateurs concernés doivent rétrograder XZ Utils vers une version sans compromis, telle que XZ Utils 5.4.6 Stable.

Il est extrêmement difficile de prévenir ce type d'attaques, en particulier lors de l'utilisation de composants open source dans les logiciels, car la sécurité de la chaîne d'approvisionnement est difficilement garantie et transparente. Nous avons déjà combattu des erreurs accidentelles dans la chaîne d'approvisionnement logicielle, mais ce risque s'est accru avec les failles de sécurité délibérément implantées pour compromettre la sécurité open source.

La plupart des développeurs ne pourront empêcher une attaque de ce type que s'ils ont une conscience aiguë de la sécurité, de solides connaissances en la matière et une certaine dose de méfiance. Il s'agit presque d'adopter la mentalité d'un acteur malveillant. Cependant, une considération majeure doit toujours porter sur les référentiels de code source qui sont contrôlés en interne (c'est-à-dire non open source). Ceux-ci ne devraient être accessibles qu'aux personnes disposant de connaissances avérées et pertinentes en matière de sécurité. Les experts en sécurité des applications pourraient envisager la mise en place de contrôles de sécurité au niveau des succursales, de sorte que seuls les développeurs expérimentés en matière de sécurité puissent apporter des modifications à la branche principale finale.

Les bénévoles sont des héros, mais il (devrait) falloir tout un village pour maintenir la sécurité des logiciels.

Pour ceux qui ne travaillent pas dans le domaine de l'ingénierie logicielle, l'idée qu'une communauté dynamique de bénévoles entretienne minutieusement des systèmes critiques pendant leur temps libre est un concept difficile à appréhender, mais cela fait partie intégrante du développement open source, et cela reste un domaine dans lequel les experts en sécurité qui protègent la chaîne d'approvisionnement représentent un risque critique.

Les logiciels open source sont un élément important de l'écosystème numérique de pratiquement toutes les entreprises, et les responsables de confiance (dont la plupart agissent de bonne foi) sont vraiment héroïques dans leur quête désintéressée du progrès technique et de l'intégrité, mais il est inapproprié de les laisser travailler de manière isolée. À l'heure où les DevSecops occupent le devant de la scène, la sécurité est une responsabilité partagée, et chaque développeur doit disposer des connaissances et des outils appropriés pour faire face aux problèmes de sécurité qu'il est susceptible de rencontrer dans son travail quotidien. La sensibilisation à la sécurité et les compétences pratiques ne devraient pas être négociables dans le processus de développement logiciel, et il appartient aux responsables de la sécurité d'influencer le changement au niveau de l'entreprise.

Mettez en place dès aujourd'hui une culture de la sécurité florissante dans votre entreprise grâce à des cours détaillés. formations de Secure Code Warrior.