Informatique

Log4j : Apache publie un nouveau correctif

Log4j : Apache publie un nouveau correctif

Apache a publié la version 2.17.0 de son correctif pour Log4j après avoir découvert des problèmes avec la version précédente, qui est sortie mardi.

Apache estime que la version 2.16 « ne protège pas toujours contre la récursion infinie dans l’évaluation de la recherche » et précise qu’elle est vulnérable à CVE-2021-45105, une vulnérabilité de déni de service dont la gravité est « élevée » (CVSS de 7.5).

« Les versions 2.0-alpha1 à 2.16.0 d’Apache Log4j2 ne protègent pas contre la récursion incontrôlée des recherches autoréférentielles. Lorsque la configuration de journalisation utilise une disposition de motif (Pattern Layout) non par défaut avec une recherche de contexte (par exemple, $${ctx:loginId}), les attaquants ayant le contrôle des données d’entrée de la carte de contexte de thread (MDC) peuvent créer des données d’entrée malveillantes contenant une recherche récursive, ce qui entraîne une StackOverflowError qui met fin au processus. Cette attaque est également connue sous le nom d’attaque DOS (Denial of Service) », explique Apache.

Des correctifs en cours de déploiement

Apache ajoute que le dernier problème a été découvert par Hideki Okamoto, d’Akamai Technologies, et un autre chercheur en vulnérabilités anonyme.

Les mesures d’atténuation comprennent l’application du correctif 2.17.0 et le remplacement de Context Lookups comme ${ctx:loginId} ou $${ctx:loginId} par des motifs Thread Context Map (%X, %mdc, ou %MDC) dans PatternLayout dans la configuration de la journalisation. Apache suggère également de supprimer les références aux Context Lookups dans la configuration, comme ${ctx:loginId} ou $${ctx:loginId}, lorsqu’elles proviennent de sources externes à l’application, comme les en-têtes HTTP ou les entrées utilisateur.

A noter : seul le fichier JAR Log4j-core est impacté par CVE-2021-45105.

Une nouvelle vulnérabilité

Vendredi, les chercheurs en sécurité en ligne ont commencé à tweeter sur des problèmes potentiels avec la version 2.16.0, certains identifiant la vulnérabilité de déni de service.

Les discussions sur Log4j ont dominé toute la semaine. La CISA a publié plusieurs avis demandant aux agences civiles fédérales des Etats-Unis d’appliquer des correctifs avant Noël, tandis que plusieurs grandes entreprises technologiques comme IBM, Cisco et VMware se sont empressées de corriger les vulnérabilités de Log4j dans leurs produits.

La société de sécurité Blumira affirme avoir trouvé un nouveau vecteur d’attaque de Log4j qui peut être exploité par le biais d’un serveur d’écoute sur une machine ou un réseau local, ce qui pourrait mettre fin à l’hypothèse selon laquelle le problème était limité aux serveurs vulnérables exposés.

D’autres entreprises de cybersécurité ont constaté que d’importants groupes de ransomware comme Conti étudient les moyens de tirer parti de cette vulnérabilité.

35 863 des artefacts Java disponibles dans Maven Central dépendent du code Log4j concerné

Vendredi, Google a publié un rapport de sécurité dans lequel James Wetter et Nicky Ringland, membres de l’équipe Open Source Insights, affirment avoir découvert que 35 863 des artefacts Java disponibles dans Maven Central dépendaient du code Log4j concerné. Cela signifie que plus de 8 % de tous les paquets sur Maven Central ont au moins une version qui est affectée par cette vulnérabilité, expliquent les deux experts.

« L’impact moyen sur l’écosystème des avis affectant Maven Central est de 2 %, la médiane étant inférieure à 0,1 % », précisent-ils.

Jusqu’à présent, près de 5 000 artefacts ont été patchés, ce qui en laisse plus de 30 000 autres. Mais les deux hommes ont noté qu’il sera difficile de résoudre le problème en raison de la profondeur de l’intégration de Log4j dans certains produits.

visualization-13.png

Image : Google.

Un problème qui pourrait durer des années

« La plupart des artefacts qui dépendent de log4j le font indirectement. Plus la vulnérabilité est profonde dans une chaîne de dépendance, plus il faut d’étapes pour la corriger. Pour plus de 80 % des paquets, la vulnérabilité se situe à plus d’un niveau, la majorité étant affectée cinq niveaux plus bas (et certains jusqu’à neuf niveaux plus bas) », écrivent les chercheurs.

« Ces paquets nécessiteront des corrections dans toutes les parties de l’arbre, en commençant par les dépendances les plus profondes. »

Les deux hommes ont poursuivi en disant qu’après avoir examiné tous les avis critiques divulgués publiquement et affectant les paquets Maven, ils ont constaté que moins de la moitié (48 %) des artefacts affectés par une vulnérabilité ont été corrigés, ce qui signifie qu’il faudra peut-être des années pour que le problème Log4j soit résolu.

Source : ZDNet.com




Source link

Articles similaires

Bouton retour en haut de la page