Ils ont identifié une autre vulnérabilité Log4j 2 et elle est marquée comme dangereuse

log4j

Il y a quelques semaines, la nouvelle des problèmes de sécurité de Log4j bouleversait de nombreux utilisateurs du réseau et c'est l'une des failles qui a le plus été exploitée et que de nombreux experts ont qualifiée de « la plus dangereuse depuis longtemps », Parmi les vulnérabilités qui ont été révélées dans le réseau, nous parlons de certaines d'entre elles ici sur le blog et cette fois nous avons trouvé les nouvelles d'un autre.

Et c'est qu'il y a quelques jours la nouvelle a été publiée qu'une autre vulnérabilité a été identifiée dans la bibliothèque Log4j 2 (qui est déjà répertorié sous CVE-2021-45105) et qui, contrairement aux deux précédents, a été classé comme dangereux, mais pas critique.

Le nouveau problème permet un déni de service et se manifeste sous forme de boucles et de terminaisons anormales lors du traitement de certaines lignes.

Vulnérabilité affecte les systèmes qui utilisent la recherche contextuelle, tels que $ {ctx: var}, pour déterminer le format de sortie du journal.

Les Log4j versions 2.0-alpha1 à 2.16.0 manquaient de protection contre la récursivité incontrôlée, Qui a permis à un attaquant de manipuler la valeur utilisée en substitution pour provoquer une boucle sans fin qui manquerait d'espace sur la pile et entraînerait le blocage du processus. En particulier, le problème s'est produit lors de la substitution de valeurs telles que "$ {$ {:: - $ {:: - $$ {:: - j}}}}".

En outre, On peut noter que les chercheurs de Blumira ont proposé une attaque contre les applications Java vulnérables qui n'acceptent pas les demandes de réseaux externes, par exemple, les systèmes de développeurs ou d'utilisateurs d'applications Java peuvent être attaqués de cette manière.

L'essence de la méthode est que s'il y a des processus Java vulnérables sur le système de l'utilisateur qui accepte les connexions réseau uniquement à partir de l'hôte local (localhost), ou traite les demandes RMI (Remote Method Invocation, port 1099), l'attaque peut être effectuée par du code JavaScript exécuté lorsque l'utilisateur ouvre une page malveillante dans le navigateur. Pour établir une connexion au port réseau d'une application Java lors d'une telle attaque, l'API WebSocket est utilisée, à laquelle, contrairement aux requêtes HTTP, aucune restriction de même origine n'est appliquée (WebSocket peut également être utilisé pour analyser les ports réseau sur le hôte pour déterminer les pilotes réseau disponibles).

Les résultats de l'évaluation de la vulnérabilité des bibliothèques associées aux dépendances avec Log4j publiés par Google 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 liés à Log4j avec des dépendances directes et indirectes ont été exposés à des vulnérabilités. À son tour, Log17j n'est utilisé comme dépendance directe du premier niveau que dans 83% des cas, et dans 4% des packages couverts par la vulnérabilité, la liaison se fait via des packages intermédiaires qui dépendent de Log21j, c'est-à-dire tell. dépendances du deuxième et du plus haut niveau (12% - le deuxième niveau, 14% - le troisième, 26% - le quatrième, 6% - le cinquième, XNUMX% - le sixième).

Le taux de réparation de la vulnérabilité laisse encore beaucoup à désirer, une semaine après l'identification de la vulnérabilité, sur 35863 4620 packages identifiés, le problème n'a été corrigé jusqu'à présent que dans 13, soit à XNUMX%.

Les modifications apportées aux packages sont nécessaires pour mettre à jour les exigences de dépendance et remplacer les anciennes liaisons de version par des versions fixes de Log4j 2 (les packages Java pratiquent la liaison à une version spécifique, et non à une plage ouverte permettant l'installation de la dernière version).

L'élimination de la vulnérabilité dans les applications Java est entravée par le fait que les programmes incluent souvent une copie des bibliothèques en livraison, et il ne suffit pas de mettre à jour la version Log4j 2 dans les packages système.

Pendant ce temps, l'Agence américaine pour la protection des infrastructures et la cybersécurité a publié une directive d'urgence exigeant des agences fédérales qu'elles identifient les systèmes d'information affectés par la vulnérabilité Log4j et installent des mises à jour qui bloquent le problème avant le 23 décembre.

Par contre, une directive a été donnée jusqu'au 28 décembre, dans laquelle les organismes avaient l'obligation de rendre compte des travaux effectués. Pour simplifier l'identification des systèmes problématiques, une liste de produits dans lesquels la manifestation d'une vulnérabilité a été confirmée a été préparée (il y a plus de 23 XNUMX applications dans la liste).

Enfin, Il convient de mentionner que la vulnérabilité a été corrigée dans Log4j 2.17 qui a été publié il y a quelques jours et les utilisateurs qui ont désactivé les mises à jour sont invités à effectuer la mise à jour correspondante, en plus du fait que le danger de la vulnérabilité est atténué par le fait que le problème ne se manifeste que sur les systèmes avec Java 8.

source: https://logging.apache.org/


Le contenu de l'article adhère à nos principes de éthique éditoriale. Pour signaler une erreur, cliquez sur c'est par ici !.

Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.