Une nouvelle 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. Ce nouveau problème permet de provoquer un déni de service et se manifeste par des boucles infinies et des arrêts soudains lors du traitement de certaines chaînes. La vulnérabilité a été corrigée dans la version récemment publiée de Log4j 2.17. Le risque de cette vulnérabilité est atténué par le fait que le problème ne se manifeste que sur des systèmes utilisant Java 8.
Les systèmes vulnérables sont ceux qui utilisent des requêtes contextuelles (Context Lookup) pour déterminer le format de sortie du journal, telles que ${ctx:var}. Dans les versions de Log4j, allant de 2.0-alpha1 à 2.16.0, il n'y avait pas de protection contre la récursion non contrôlée, ce qui permettait à un attaquant, par le biais de manipulations avec la valeur utilisée dans le remplacement, de provoquer une boucle infinie entraînant l'épuisement de l'espace dans la pile et l'arrêt brutal du processus. En particulier, le problème se produisait lors du remplacement de valeurs telles que «${${::-${::-$${::-j}}}}».
De plus, il convient de noter que des chercheurs de l'entreprise Blumira ont proposé une variante d'attaque contre des applications Java vulnérables qui ne reçoivent pas de requêtes réseau externes, par exemple, des systèmes de développeurs ou d'utilisateurs d'applications Java peuvent être attaqués de cette manière. Le principe de la méthode repose sur le fait que, lorsque des processus Java vulnérables sont présents sur le système de l'utilisateur, n'acceptant des connexions réseau qu'à partir de l'hôte local (localhost) ou traitant des requêtes RMI (Remote Method Invocation, port 1099), une attaque peut être réalisée par du code JavaScript exécuté lors de l'ouverture d'une page malveillante dans le navigateur des utilisateurs. Pour établir une connexion au port réseau de l'application Java lors d'une telle attaque, l'API WebSocket est utilisée, qui, contrairement aux requêtes HTTP, ne subit pas de restrictions same-origin (WebSocket peut également être utilisé pour scanner les ports réseau sur l'hôte local afin de déterminer les gestionnaires réseau disponibles).
Les résultats d'évaluation des vulnérabilités des bibliothèques publiés par Google sont également d'un grand intérêt, concernant les dépendances liées à Log4j. Selon Google, le problème touche 8 % de tous les packages dans le repository Maven Central. En particulier, 35 863 packages Java liés à Log4j présentent des vulnérabilités, que ce soit par des dépendances directes ou indirectes. Log4j est utilisé en tant que dépendance directe de premier niveau seulement dans 17 % des cas, tandis que dans 83 % des packages touchés par la vulnérabilité, la liaison se fait par le biais de packages intermédiaires dépendants de Log4j, c'est-à-dire des dépendances de deuxième niveau ou plus (21 % - deuxième niveau, 12 % - troisième, 14 % - quatrième, 26 % - cinquième, 6 % - sixième). Le rythme de correction de la vulnérabilité laisse encore à désirer ; une semaine après la découverte de la vulnérabilité, parmi les 35 863 packages identifiés, le problème n'a été résolu que pour 4 620 d'entre eux, soit 13 %.
Entre-temps, l'Agence américaine de cybersécurité et de protection des infrastructures a publié une directive d'urgence, obligeant les agences fédérales à identifier les systèmes d'information vulnérables à Log4j et à installer les mises à jour qui bloquent le problème d'ici le 23 décembre. D'ici le 28 décembre, les organisations doivent rendre compte des travaux effectués. Pour faciliter l'identification des systèmes problématiques, une liste de produits dans lesquels la vulnérabilité a été confirmée a été préparée (la liste contient plus de 23 000 applications).
Source : opennet.ru
