Tout est prêt pour le week-end ? Pas si vite. Hier, EZpublish-france.fr a résumé tous les CVE log4j et logback connus à ce jour.
Depuis le début de la saga critique du jour zéro de log4j la semaine dernière, les experts en sécurité ont maintes et maintes fois recommandé la version 2.16 comme la version la plus sûre à utiliser.
Cela change aujourd’hui avec la sortie de la version 2.17.0 qui corrige une vulnérabilité de déni de service (DoS) apparemment mineure, mais de gravité « élevée » qui affecte log4j 2.16.
Et, oui, ce bug DoS est accompagné d’un autre identifiant : CVE-2021-45105.
Récursivité infinie, libérations finies ?
La suspicion d’un bug DoS affectant log4j 2.16.0 est apparue sur le projet JIRA d’Apache à propos de il y a trois jours, peu après la 2.15.0, s’est avéré vulnérable à une vulnérabilité DoS mineure (CVE-2021-45046).
Comme signalé par EZpublish-france.fr hier, la gravité de CVE-2021-45046 est passée de faible (3,7) à critique (9,0) par Apache, après que de nouveaux contournements aient permis l’exfiltration de données via cet exploit.
« Si une substitution de chaîne est tentée pour une raison quelconque sur la chaîne suivante, cela déclenchera une récursivité infinie et l’application se bloquera », indique le problème JIRA, avec une charge utile PoC :
${${::-${::-$${::-j}}}}
Il y a quelques heures, des chercheurs en sécurité, dont vx-underground et Hacker Fantastique tweeté à propos d’une possible faille de déni de service affectant également la version 2.16 de log4j :
Nouvel exploit vendredi, comme le veut la tradition : les chercheurs ont découvert que la version 2.16 de Log4J est vulnérable au DoS via « ${${::-${::-$${::-j}}}} »
Plus d’informations: https://t.co/pzeWiQEa68
– vx-underground (@vxunderground) 17 décembre 2021
Et il s’avère qu’après avoir débattu de la question au cours des trois derniers jours, Apache a attribué un nouveau CVE et a déployé une nouvelle version.
log4j 2.17.0 sorti aujourd’hui, corrige DoS
Suivi comme CVE-2021-45105, et noté « Élevé » (7,5) sur l’échelle CVSS, la faille DoS dans log4j 2.16 existe car Log4j2 « ne protège pas toujours d’une récursivité infinie dans l’évaluation de la recherche ».
Bien que les recherches JNDI aient été complètement désactivées dans Log4j 2.16, les recherches autoréférentielles restaient possibles dans certaines circonstances.
« Apache Log4j2 versions 2.0-alpha1 à 2.16.0 n’a pas protégé contre la récursivité incontrôlée des recherches auto-référentielles », déclarent les notes de version de la version vues par EZpublish-france.fr.
« Lorsque la configuration de la journalisation utilise une disposition de modèle autre que celle par défaut avec une recherche de contexte (par exemple, « ${dollar}${dollar}{ctx:loginId}« ), les attaquants contrôlant les données d’entrée de Thread Context Map (MDC) peuvent créer des données d’entrée malveillantes contenant une recherche récursive, ce qui entraîne un StackOverflowError cela mettra fin au processus. »
Pour corriger la vulnérabilité, log4j version 2.17.0 (pour Java 8) a été sorti aujourd’hui et permet uniquement aux « chaînes de recherche dans la configuration » de se développer de manière récursive. Dans toute autre utilisation, seule la recherche de niveau supérieur serait résolue, et non les recherches imbriquées.
La version devrait atteindre le plus grand référentiel de packages Java, Maven Central plus tard aujourd’hui.
Bien qu’Apache ait officiellement publié des détails sur la prochaine version 2.17.0 jusqu’à présent, les commits GitHub vus par EZpublish-france.fr indiquent qu’une version 2.12.3 pourrait également être en route pour ceux des versions de la branche 2.12.x.
Google : plus de 35 000 packages Java ont des failles Log4j
Le développement intervient à peu près en même temps que l’analyse de Google qui révèle que plus de 35 000 packages Java contiennent des vulnérabilités log4j.
« Plus de 35 000 packages Java, représentant plus de 8 % du référentiel Maven Central (le référentiel de packages Java le plus important), ont été affectés par les vulnérabilités log4j récemment divulguées », expliquent James Wetter et Nicky Ringland de l’équipe Open Source Insights de Google dans celui d’hier article de blog.
Selon Google, la grande majorité des packages Java vulnérables dans Maven Central empruntent log4j « indirectement », c’est-à-dire que log4j est une dépendance d’une dépendance utilisée par le package, un concept également appelé dépendances transitives.
Sur les 35 863 packages identifiés par Google, à peu près 7 000 ont emprunté directement log4j, ce qui indique que tous les développeurs n’ont peut-être pas une visibilité adéquate sur leur logiciel :
« Le manque de visibilité des utilisateurs sur leurs dépendances et leurs dépendances transitives a rendu l’application des correctifs difficile ; il a également rendu difficile la détermination du rayon d’action complet de cette vulnérabilité », explique Google.
En regardant l’historique des vulnérabilités critiques divulguées publiquement affectant les packages Maven, et le fait que moins de 48% de ces packages avaient un correctif pour ces derniers, les chercheurs de Google s’attendent à « une longue attente, probablement des années » avant que les failles log4j ne soient complètement éliminées de tous les packages Java. .
Comme indiqué par EZpublish-france.fr, les acteurs de la menace ciblent les serveurs vulnérables avec des exploits log4j pour pousser les logiciels malveillants, le gang de ransomware Conti visant spécifiquement les serveurs VMWare vCenter vulnérables.
En tant que telles, les organisations doivent effectuer une mise à niveau vers les dernières versions de log4j et continuer à surveiller les mises à jour d’Apache.