Risque(s)

• Exécution de code arbitraire à distance

Systèmes affectés

• Apache Log4j versions 2.0 à 2.14.1
• Apache Log4j versions 1.x (versions obsolètes)

Résumé

Une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache log4j. Cette bibliothèque est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE.

Cette vulnérabilité permet à un attaquant de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d'une page d'authentification qui journalise les erreurs d'authentification.

Des preuves de concept ont déjà été publiées et des codes d'exploitation sont susceptibles d'être rapidement développés.

Contournement provisoire

Il est fortement recommandé d'utiliser la version 2.15.0 de log4j dès que possible. Cependant, en cas de difficulté de migration vers cette version, les contournements ci-dessous peuvent être appliqués temporairement :

Pour les applications utilisant les versions 2.7.0 et ultérieures de la bibliothèque log4j, il est possible de se prémunir contre toute attaque en modifiant le format des évènements à journaliser avec la syntaxe %m{nolookups} pour les données qui seraient fournies par l'utilisateur.

Cette modification impose de modifier le fichier de configuration de log4j pour produire une nouvelle version de l'application. Cela requiert donc d'effectuer de nouveau les étapes de validation technique et fonctionnelle avant le déploiement de cette nouvelle version.

Pour les applications utilisant les versions 2.10.0 et ultérieures de la bibliothèque log4j, il est également possible de se prémunir contre toute attaque en modifiant le paramètre de configuration log4j2.formatMsgNoLookups à la valeur true, par exemple lors du lancement de la machine virtuelle Java avec l'option -Dlog4j2.formatMsgNoLookups=true. Une autre alternative consiste à supprimer la classe JndiLookup dans le paramètre classpath pour éliminer le vecteur principal d'attaque (les chercheurs n'excluent pas l'existence d'un autre vecteur d'attaque).

De manière générale, il semble que l'utilisation d'un environnement d'exécution Java en version 8u121 ou ultérieure permette de se prémunir contre le principal vecteur d'attaque évoqué par les chercheurs à l'origine de la découverte.

À noter que les développeurs de la bibliothèque confirment que les versions 1.x sont également affectées.

Solution

Il est fortement recommandé aux utilisateurs d'applications ou de logiciels sur étagère basés sur la technologie Java/J2EE :

• de filtrer les flux sortants des serveurs pour les limiter aux seuls flux autorisés vers des services de confiance ;
• de prendre contact avec le développeur ou l'éditeur pour vérifier s'ils sont exposés à cette vulnérabilité et si un correctif est disponible.

 

Il est fortement recommandé aux développeurs/éditeurs de mettre à jour log4j à la version 2.15.0 et de fournir une nouvelle version de leur logiciel dans les plus brefs délais.

Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).

---

La mise à jour d’un produit ou d’un logiciel est une opération délicate qui doit être menée avec prudence. Il est notamment recommandé d’effectuer des tests autant que possible. Des dispositions doivent également être prises pour garantir la continuité de service en cas de difficultés lors de l’application des mises à jour comme des correctifs ou des changements de version.

Documentation

• Bulletin de sécurité Apache du 09 décembre 2021
  https://logging.apache.org/log4j/2.x/security.html
• Référence CVE CVE-2021-44228
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228