La mobilisation générale pour corriger la faille dans la bibliothèque de journalisation Log4j pourrait bien s’émousser après l’annonce par la Fondation Apache d’une énième version du composant open source. En effet, la 2.17.0 corrige une faille dans l’itération 2.16.0 provoquant un déni de service. La semaine dernière, constructeurs et fournisseurs de solutions IT préconisaient de mettre à jour en urgence la version 2.16.0, qui s’est donc révélée elle-même vulnérable. Ce bug est classé sous la référence CVE-2021-45105.

La suspicion d'une faille DoS affectant log4j 2.16.0 est apparue sur le projet Jira d'Apache il y a quelques jours, peu après que la version 2.15.0 se soit avérée être vulnérable à une vulnérabilité DoS mineure (CVE-2021-45046). Cette dernière est passée en terme de sévérité de faible (3,7) à critique (9,0) par Apache, après la découverte d’une capacité de contournement et d’exfiltration de données. « Si une substitution de chaîne est tentée pour quelque raison que ce soit sur la chaîne suivante, cela déclenchera une récursion infinie et l’application plantera », souligne le ticket d’incident Jira en présentant la chaîne incriminée : ${${::-${::-$${::-j}}}}.

La sécurité des projets open source en question

Mais, des chercheurs en sécurité vx-underground et Hacker Fantastic ont tweeté qu’une faille DoS affectait aussi la version 2.16.0 de Log4j. La CVE-2021-45105 est jugée à un haut niveau de risque (7,5). Selon les spécialistes, la version 2.16.0 ne protège pas contre « la récursion infinie dans la méthode de recherche ». Si les recherches JDNI (Java Naming and Directory Interface) ont été complètement désactivées dans cette version, les recherches autoréférentielles demeuraient possibles dans certaines circonstances.

Cette façon de gérer de manière erratique les patchs sur Log4j pose problème aux administrateurs systèmes qui sont en attente d’une version stable de la bibliothèque de journalisation. L’histoire n’est pas sans rappeler l’affaire des failles Spectre et Meltdown touchant les puces Intel et AMD et où Microsoft a eu du mal à fournir un correctif efficace et complet. On peut également s’interroger sur la capacité de la Fondation Apache et des mainteneurs de Log4j pour en assurer seuls la fiabilité. On se souvient de l’affaire Heartbleed dans OpenSSL qui avait mobilisé les grands acteurs de l’IT. Une structure avait même été créée sous les auspices de Google et de la Fondation Linux : Core Infrastructure Initiative. Dotée d’une enveloppe globale de 3,6 millions de dollars, elle avait pour objectif d’améliorer la sécurité des logiciels open source. Tout comme la création récente de l’OpenSSF.