Une autre vulnérabilité a été identifiée dans la bibliothèque Log4j 2 (CVE-2021-45105), qui, contrairement aux deux problèmes précédents, est classée comme dangereuse, mais non critique. Le nouveau problème permet de provoquer un déni de service et se manifeste sous forme de boucles et de crashs lors du traitement de certaines lignes. La vulnérabilité a été corrigée dans la version Log4j 2.17 publiée il y a quelques heures. Le danger de la vulnérabilité est atténué par le fait que le problème n'apparaît que sur les systèmes dotés de Java 8.
La vulnérabilité affecte les systèmes qui utilisent des requêtes contextuelles (Context Lookup), telles que ${ctx:var}, pour déterminer le format de sortie du journal. Les versions de Log4j de 2.0-alpha1 à 2.16.0 manquaient de protection contre la récursion incontrôlée, ce qui permettait à un attaquant de manipuler la valeur utilisée dans la substitution pour provoquer une boucle, entraînant un épuisement de l'espace de pile et un crash. En particulier, le problème s'est produit lors du remplacement de valeurs telles que "${${::-${::-$${::-j}}}}".
De plus, on peut noter que les chercheurs de Blumira ont proposé une option pour attaquer les applications Java vulnérables qui n'acceptent pas les requêtes du réseau externe ; par exemple, les systèmes des développeurs ou des utilisateurs d'applications Java peuvent être attaqués de cette manière. L'essence de la méthode est que s'il existe des processus Java vulnérables sur le système de l'utilisateur qui acceptent les connexions réseau uniquement à partir de l'hôte local ou traitent les requêtes RMI (Remote Method Invocation, port 1099), l'attaque peut être effectuée par le code JavaScript exécuté. lorsque les utilisateurs ouvrent une page malveillante dans leur navigateur. Pour établir une connexion au port réseau d'une application Java lors d'une telle attaque, on utilise l'API WebSocket, à laquelle, contrairement aux requêtes HTTP, les restrictions de même origine ne sont pas appliquées (WebSocket peut également être utilisé pour analyser les ports réseau sur le réseau local). hôte afin de déterminer les gestionnaires de réseau disponibles).
Les résultats publiés par Google sur l'évaluation de la vulnérabilité des bibliothèques associées aux dépendances Log4j sont également intéressants. Selon Google, le problème affecte 8 % de tous les packages du référentiel Maven Central. En particulier, 35863 4 packages Java associés à Log4j via des dépendances directes et indirectes ont été exposés à des vulnérabilités. Dans le même temps, Log17j n'est utilisé comme dépendance directe de premier niveau que dans 83 % des cas, et dans 4 % des packages concernés, la liaison est effectuée via des packages intermédiaires qui dépendent de Log21j, c'est-à-dire dépendances du deuxième niveau et supérieur (12% - deuxième niveau, 14% - troisième, 26% - quatrième, 6% - cinquième, 35863% - sixième). Le rythme de correction de la vulnérabilité laisse encore beaucoup à désirer : une semaine après l'identification de la vulnérabilité, sur 4620 13 paquets identifiés, le problème a été résolu jusqu'à présent dans seulement XNUMX XNUMX, soit à XNUMX%.
Dans le même temps, l'Agence américaine de cybersécurité et de protection des infrastructures a publié une directive d'urgence exigeant que les agences fédérales identifient les systèmes d'information affectés par la vulnérabilité Log4j et installent des mises à jour qui bloquent le problème d'ici le 23 décembre. D'ici le 28 décembre, les organisations sont tenues de rendre compte de leur travail. Pour simplifier l'identification des systèmes problématiques, une liste de produits dont il a été confirmé qu'ils présentent des vulnérabilités a été préparée (la liste comprend plus de 23 XNUMX applications).
Source: opennet.ru