thedevappsecguy/log4j-mitigation-cve-2021-44228--cve-2021-45046--cve-2021-45105--cve-2021-44832Log4J CVE-2021-44228 : Aide-mémoire d'atténuation
Mise à jour - 28 décembre 2021
CVE-2021-44832 : Apache Log4j2 vulnérable à une exécution de code à distance (RCE) via l'Appender JDBC lorsqu'un attaquant contrôle la configuration.
Corrigé dans Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) et 2.3.2 (Java 6)
Mise à jour - 17 décembre 2021
Dans la nuit, Apache a divulgué que la version 2.16 de Log4j est également vulnérable à une attaque par déni de service dont l'impact est un crash complet de l'application ; la sévérité est classée comme Élevée (7.5). Le CVE-2021-45105 a été émis, et une nouvelle version corrigée (2.17) a été publiée par Apache, dont la mise à niveau est recommandée.
Contexte :
Les discussions sur Internet étaient en ébullition à propos d'une vulnérabilité 0-day (pouvant conduire à une exécution de code à distance) dans la célèbre bibliothèque de journalisation Log4J d'Apache pour Java. Cette vulnérabilité particulière – suivie sous le nom CVE-2021-44228 avec le score CVSS maximal « critique » de 10 – réside dans la capacité de recherche (lookup) de Log4J, combinée à JNDI (Java Naming and Directory Interface). Ce problème est très répandu car de nombreux développeurs ignoraient que Log4J était dangereux à utiliser avec des entrées non filtrées.
L'impact le plus significatif est qu'un attaquant peut amener une chaîne de caractères jusqu'au journaliseur qui, une fois traitée par Log4J, exécute du code arbitraire. Les premiers exemples de cette attaque utilisaient le chemin ${jndi:ldap}, ce qui pouvait conduire au chargement de code arbitraire depuis une URL distante. Ce chemin est partiellement atténué par l'utilisation de runtimes Java plus récents qui bloquent par défaut le chargeur de classes basé sur URL. Malheureusement, une version moderne de Java peut ne pas suffire à empêcher l'exploitation, car l'application elle-même peut exposer des classes qui peuvent être utilisées pour exécuter du code arbitraire.
L'architecture JNDI :
Mesures d'atténuation pour différents environnements :
Mise à jour - 17 décembre 2021
Vulnérabilité de sécurité CVE-2021-45105
Détails :
Les versions d'Apache Log4j2 allant de 2.0-alpha1 à 2.16.0 ne protégeaient pas contre la récursion incontrôlée provenant de recherches auto-référentielles. Lorsque la configuration de journalisation utilise une disposition de motifs (Pattern Layout) non par défaut avec une recherche de contexte (Context Lookup) (par exemple, $${ctx:loginId}), les attaquants qui contrôlent les données d'entrée du Thread Context Map (MDC) peuvent concevoir des données d'entrée malveillantes contenant une recherche récursive, entraînant une StackOverflowError qui terminera le processus. C'est ce qu'on appelle aussi une attaque DOS (Déni de service).
Mesure d'atténuation :
À partir de la version 2.17.0 (pour Java 8), seules les chaînes de recherche de la configuration sont développées de manière récursive ; dans tout autre usage, seule la recherche de niveau supérieur est résolue, et les recherches imbriquées ne sont pas résolues.
Dans les versions antérieures, ce problème peut être atténué en s'assurant que votre configuration de journalisation fait ce qui suit :
Dans PatternLayout de la configuration de journalisation, remplacez les recherches de contexte comme ${ctx:loginId} ou $${ctx:loginId} par les motifs du Thread Context Map (%X, %mdc ou %MDC).
Sinon, dans la configuration, supprimez les références aux recherches de contexte comme ${ctx:loginId} ou $${ctx:loginId} lorsqu'elles proviennent de sources externes à l'application, telles que les en-têtes HTTP ou les entrées utilisateur.
Mise à jour - 13 décembre 2021
** Log4j (version 2.16.0 – 2021-12-13) dispose de deux fonctionnalités améliorées :**
---------------!!Il est fortement recommandé de passer à la dernière version disponible car les recherches de messages sont désactivées par défaut.!!------------
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
Désactiver JNDI par défaut. Exiger que log4j2.enableJndi soit défini sur true pour autoriser JNDI.
Supprimer complètement la prise en charge des recherches de messages (Message Lookups)
Nouvelle mise à jour :
------------------CVE-2021-45046-----------------
Les motifs de messages de contexte de thread (Thread Context Message Pattern) et les motifs de recherche de contexte (Context Lookup Pattern) d'Apache Log4j2 sont vulnérables à une attaque par déni de service.
Mesure d'atténuation :
Atténuation Log4j 1.x : Log4j 1.x n'est pas affecté par cette vulnérabilité.
Atténuation Log4j 2.x : Mettez en œuvre l'une des techniques d'atténuation ci-dessous.
Les utilisateurs de Java 8 (ou version ultérieure) doivent passer à la version 2.16.0. Les utilisateurs nécessitant Java 7 doivent passer à la version 2.12.2 lorsqu'elle sera disponible (travail en cours, attendue prochainement).
Sinon, supprimez la classe JndiLookup du classpath : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Notez que seul le fichier JAR log4j-core est affecté par cette vulnérabilité. Les applications utilisant uniquement le fichier JAR log4j-api sans le fichier JAR log4j-core ne sont pas affectées par cette vulnérabilité.
------------------CVE-2021-44228-------------------
Mesure d'atténuation
Atténuation Log4j 1.x : Log4j 1.x ne dispose pas de recherches (Lookups), le risque est donc plus faible. Les applications utilisant Log4j 1.x ne sont vulnérables à cette attaque que lorsqu'elles utilisent JNDI dans leur
configuration. Un CVE distinct (CVE-2021-4104) a été déposé pour cette vulnérabilité. Pour atténuer : auditez votre configuration de journalisation pour vous assurer qu'aucun JMSAppender n'y est configuré.
Les configurations Log4j 1.x sans JMSAppender ne sont pas affectées par cette vulnérabilité.
Atténuation Log4j 2.x : Mettez en œuvre l'une des techniques d'atténuation ci-dessous.
Les utilisateurs de Java 8 (ou version ultérieure) doivent passer à la version 2.16.0.
Les utilisateurs nécessitant Java 7 doivent passer à la version 2.12.2 lorsqu'elle sera disponible (travail en cours, attendue prochainement).
Sinon, supprimez la classe JndiLookup du classpath : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Notez que seul le fichier JAR log4j-core est affecté par cette vulnérabilité. Les applications utilisant uniquement le fichier JAR log4j-api sans le fichier JAR log4j-core ne sont pas affectées par cette vulnérabilité.
