Faille Log4j, retour sur une série de bugs et de correctifs…

Ces dernières semaines, les failles Log4j ont fait couler beaucoup d’encre et il y a vraiment de quoi s’inquiéter à la lumière des évènements les plus récents. Déroutés, les administrateurs systèmes ne savent plus trop comment réagir. En l’espace de 10 jours fin décembre, Apache Software Foundation a déployé 3 correctifs pour donner suite aux découvertes des failles de sa bibliothèque logicielle.

Que s’est-il passé chez Apache ?

Log4j est un programme connu principalement par les développeurs d’applications web et autres professionnels spécialisés. Si ces incidents enflamment autant le web, c’est parce que Log4j est utilisé par des millions de logiciels et d’applications web.

Une faille référencée sous le doux nom de CVE-2021-44228 a été découverte dans la bibliothèque de journalisation et publiée le 9 décembre. Dans la foulée, les développeurs déploient la version 2.15 pour corriger le bogue. Baptisée Log4Shell, la faille a été signalée à Apache par un chercheur qui travaille chez Alibaba Cloud. Ce dernier n’a pas découvert la faille, il tout simplement découvert qu’un utilisateur anonyme a publié les détails de la faille sur un site chinois et n’a pas hésité à le préciser. Des experts ont suspecté une faille DoS, dans le cadre du projet Jira d’Apache.

Log4Shell obtient rapidement le score CVSS de 10/10, ce qui signifie que le faille est extrêmement facile à exploiter. S’en est suivi alors une véritable ruée vers la faille en question. De nombreux pirates se sont empressés de l’exploiter.

Après la publication du correctif, une autre vulnérabilité a été découverte le 14 décembre. Présentée sous la référence CVE 2021-45046, cette faille indique que le dernier patch était « incomplet dans certaines configurations autres que celles par défaut ». La description du CVE d’indiquer que « Cela pourrait permettre aux attaquants… de créer des données d’entrée malveillantes à l’aide d’un modèle de recherche JNDI, ce qui entraînerait une attaque par déni de service (DoS) ».

Nouveau patch, nouveau bug, nouveau patch…

La version 2.16 sort aussitôt pour y remédier, notamment en désactivant la fonctionnalité JNDI et la prise en charge des modèles de recherche de messages. Les administrateurs qui viennent d’appliquer le nouveau patch pensaient alors être mieux protégés, il n’est est rien.

Comme on dit, jamais deux sans trois. Un troisième bogue a été découvert. Référencé VCE-2021-45105, ce bogue de récursivité infinie qui affiche une note CVSS de 7,5/10 était présent depuis 2.0-alpha1 et il persiste sur la version 2.16. Ni une ni deux, la description de cette vulnérabilité a rapidement atterri sur Twitter.  Finalement peu avant les fêtes de fin d’année, la version 2.17 de Log4j est déployée pour rectifier le tir.

Les entreprises américaines qui n’auraient pas, , en ce début janvier 2022, patché Log4j pour protéger les données de leurs utilisateurs, seront sanctionnés par la FTC.

Le débat relancé sur la sécurité des projets open source

Ces évènements ne sont pas sans se rappeler la difficulté de Microsoft à déployer des correctifs efficaces pour résoudre les failles baptisées Spectre et Meltdown, découvertes sur les puces Intel et AMD.

Le débat est relancé sur la sécurité des projets open source dont les patchs sont manifestement gérés de manière erratique, sans tendance cohérente en termes de sécurisation des utilisateurs finaux. On se souvient également de l’affaire Heatbleed qui a touché OpenSSL. Il a fallu mobiliser les géants de l’IT, notamment Google et la Fondation Linux pour en venir à bout et pour donner un coup de pouce à la sécurisation des logiciels open source dans leur ensemble. Par ailleurs, quid du tout frais OpenSSF ?

Articles récents