Vous buvez de l’eau du robinet tous les jours, n’est-ce pas ? Savez-vous qui a inventé le mécanisme de filtrage qui rend l’eau pure et propre ?… Eh bien, est-ce vraiment important pour vous ?
Savez-vous que ce mécanisme est exactement le même dans tous les robinets de toutes les maisons de tous les pays ? Savez-vous que cette pièce, spécialisée, est l’œuvre d’un ingénieur qui le fait par amour de l’art ? Pouvez-vous imaginer ce qui peut arriver si cette personne a une mauvaise journée ?
Parlons de la librairie XZ Utils et pourquoi ce n’est pas une bonne idée de compter sur un seul fournisseur et de le bourrer. Parlons de la librairie XZ Utils et de son dernier développeur, Jia Tan.
Oui, le logiciel open source peut nous offrir un certain nombre d’avantages en termes de prix (oui, parce qu’il est « gratuit »), de transparence, de collaboration et d’adaptabilité, mais il comporte également un risque en ce qui concerne la sécurité et la confiance excessive que nous plaçons en tant qu’utilisateurs.
Que s’est-il passé ?
Le 29 mars dernier, Red Hat, Inc. annonçait la vulnérabilité CVE-2024-3094, avec un score de 10 sur l’échelle de Common Vulnerability Scoring System, et donc une vulnérabilité critique, qui compromettait les serveurs SSH affectés.
Cette vulnérabilité affectait le paquet XZ Utils, qui est un ensemble d’outils logiciels fournissant la compression et la décompression de fichiers à l’aide de l’algorithme LZMA/LZMA2, et qui est inclus dans les principales distributions Linux. Si elle n’avait pas été découverte, elle aurait pu être très grave, car il s’agissait d’un code malveillant de type backdoor qui donnerait un accès à distance non autorisé aux systèmes affectés par SSH.
La vulnérabilité a commencé dans la version 5.6.0 de XZ, et affecte également la version 5.6.1.
Au cours du processus de compilation de liblzma, il extrait un fichier de test camouflé existant dans le code source, puis utilisé pour modifier des fonctions spécifiques dans le code liblzma. Le résultat est une librairie liblzma modifiée, qui peut être utilisée par n’importe quel logiciel lié à celle-ci, interceptant et modifiant l’interaction des données avec la librairie.
Ce processus de mise en place d’une porte dérobée en XZ est la dernière partie d’une campagne qui s’est étendue sur 2 ans d’opérations, principalement de type HUMNIT (intelligence humaine) de la part de l’utilisateur Jia Tan.
L’utilisateur Jia Tan a créé son compte Github en 2021, effectuant son premier commit au dépôt XZ le 6 février 2022. Plus récemment, le 16 février 2024, un fichier malveillant serait ajouté sous le nom de “build-to-host.m4” dans .gitignore, puis incorporé avec le lancement du paquet, pour finalement incorporer le 9 mars 2024 la backdoor cachée dans deux fichiers de test :
- tests/files/bad-3-corrupt_lzma2.xz
- tests/files/good-large_compressed.lzma
Comment ils l’ont remarqué ?
La principale personne chargée de localiser ce problème est Andres Freund.
Il s’agit de l’un des ingénieurs logiciels les plus importants de Microsoft, qui effectuait des tâches de micro-benchmarking. Au cours de ses tests, il s’est rendu compte que les processus sshd utilisaient une quantité de CPU inhabituelle même si les sessions n’étaient pas établies.
Après avoir profilé sshd, il a vu beaucoup de temps CPU dans la librairie liblzma. Cela a à son tour rappelé une plainte récente et étrange de Valgrind concernant les tests automatisés dans PostgreSQL. Ce comportement aurait pu être négligé et ne pas être découvert, ce qui aurait entraîné une violation majeure de la sécurité des serveurs SSH Debian/Ubuntu
Selon Andres Freund lui-même, il a fallu une série de coïncidences pour trouver cette vulnérabilité, c’était une question de chance de l’avoir trouvée.
Ce qui a déclenché les alarmes de Freund était un petit retard de seulement 0,5 sec sur les connexions ssh, qui, bien que cela semble très peu, l’a amené à enquêter plus en profondeur et à rencontrer le problème et le chaos potentiel qu’il aurait pu générer.
Cela souligne l’importance de surveiller l’ingénierie logicielle et les pratiques de sécurité. La bonne nouvelle est que la vulnérabilité a été trouvée dans releases très tôt du logiciel, de sorte que dans le monde réel, elle n’a eu pratiquement aucun effet, grâce à la détection rapide de ce code malveillant. Mais cela nous fait réfléchir à ce qui aurait pu arriver, s’il n’avait pas été détecté à temps. Ce n’est ni la première fois que cela se produit, ni la dernière fois que cela se produira. L’avantage de l’Open Source est que cela a été rendu public et que l’impact peut être évalué, dans d’autres cas où il n’y a pas une telle transparence, l’impact peut être plus difficile à évaluer et donc à remédier.
Réflexion
Avec ce qui s’est passé, nous pouvons mettre en évidence à la fois des points positifs et négatifs liés à l’utilisation de l’open source.
Comme points positifs, nous pouvons trouver la transparence et la collaboration entre les développeurs du monde entier. Avoir une communauté vigilante, chargée de détecter et de signaler les menaces de sécurité potentielles, et avoir de la flexibilité et de l’adaptabilité, car la nature de l’open source permet d’adapter et de modifier le logiciel en fonction des besoins spécifiques.
En ce qui concerne le inconvénients, nous trouvons la vulnérabilité aux attaques malveillantes, comme c’est le cas avec les actions de développeurs avec des intentions malveillantes. Les utilisateurs sont convaincus que le logiciel ne contient pas de code malveillant, ce qui peut conduire à un faux sentiment de sécurité. De plus, en raison du nombre de contributions qui existent et de la complexité même du logiciel, on peut dire qu’il est très difficile de vérifier de manière exhaustive le code.
Si nous ajoutons à cela l’existence de librairies gérées par une personne ou un très petit groupe de personnes, le risque de point de défaillance unique est plus élevé. Dans ce cas, ce besoin ou cet avantage d’avoir plus de personnes contribuant est ce qui a causé le problème.
En conclusion, bien que les logiciels open source puissent nous offrir un certain nombre d’avantages en termes de transparence, de collaboration et d’adaptabilité, ils peuvent également présenter des inconvénients ou des défis en termes de sécurité et de confiance que nous plaçons en tant qu’utilisateurs.
L’équipe éditoriale de Pandora FMS est composée d’un groupe de rédacteurs et de professionnels de l’informatique ayant un point commun : leur passion pour la surveillance des systèmes informatiques. L’équipe éditoriale de Pandora FMS est composée d’un groupe de rédacteurs et de professionnels de l’informatique ayant un point commun : leur passion pour la surveillance des systèmes informatiques.
