Log4shell-detector informations générales

Annonce Apache : Vulnérabilités de sécurité d'Apache Log4j

Source : https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046

Cette page répertorie toutes les vulnérabilités de sécurité corrigées dans les versions publiées d'Apache Log4j 2. Chaque vulnérabilité se voit attribuer une note d'impact sur la sécurité par l'équipe de sécurité d'Apache Logging. Veuillez noter que cette note peut varier d'une plate-forme à l'autre. Nous indiquons également les versions d'Apache Log4j que la faille est censée affecter, et lorsqu'une faille n'a pas été vérifiée, nous indiquons la version avec un point d'interrogation.

Remarque : Les vulnérabilités qui ne sont pas des vulnérabilités de Log4j mais qui ont été signalées de manière incorrecte contre Log4j ou pour lesquelles Log4j fournit une solution de contournement sont listées à la fin de cette page.

Veuillez noter que Log4j 1.x a atteint sa fin de vie et n'est plus pris en charge. Les vulnérabilités signalées après août 2015 contre Log4j 1.x n'ont pas été vérifiées et ne seront pas corrigées. Les utilisateurs doivent passer à Log4j 2 pour obtenir les correctifs de sécurité.

Veuillez noter que les correctifs binaires ne sont jamais fournis. Si vous devez appliquer un correctif de code source, utilisez les instructions de construction pour la version d'Apache Log4j que vous utilisez. Pour Log4j 2, il s'agit du fichier BUILDING.md. Ce fichier se trouve dans le sous-répertoire racine d'un distributeur de sources.

Si vous avez besoin d'aide pour construire ou configurer Log4j ou pour suivre les instructions visant à atténuer les vulnérabilités connues énumérées ici, veuillez envoyer vos questions à la liste de diffusion publique des utilisateurs de Log4j.

Si vous avez rencontré une vulnérabilité de sécurité non répertoriée ou un autre comportement inattendu ayant un impact sur la sécurité, ou si les descriptions données ici sont incomplètes, veuillez les signaler en privé à l'équipe de sécurité de Log4j via private@logging.apache.org. Merci.

14 décembre 2021 : Corrigé dans Log4j 2.12.2 et Log4j 2.16.0

CVE-2021-45046

CVE-2021-45046 : Apache Log4j2 Thread Context Message Pattern et Context Lookup Pattern vulnérables à une attaque par déni de service.

Gravité

Modérée

Score CVSS de base

3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)

Versions concernées

Toutes les versions de 2.0-beta9 à 2.12.1 et de 2.13.0 à 2.15.0.

Description

Il a été découvert que la correction de la CVE-2021-44228 dans Apache Log4j 2.15.0 était incomplète dans certaines configurations qui ne sont pas par défaut. Cela pourrait permettre à des attaquants ayant le contrôle des données d'entrée de Thread Context Map (MDC) lorsque la configuration de journalisation utilise un Pattern Layout non par défaut avec soit un Context Lookup (par exemple, $${ctx:loginId}) ou un Thread Context Map pattern (%X, %mdc, ou %MDC) pour créer des données d'entrée malveillantes à l'aide d'un pattern JNDI Lookup résultant en une attaque par déni de service (DOS). Log4j 2.15.0 restreint par défaut les recherches LDAP JNDI à localhost. Notez que les mesures d'atténuation précédentes impliquant une configuration telle que la définition de la propriété système log4j2.noFormatMsgLookup à true n'atténuent PAS cette vulnérabilité spécifique.

Mesures d'atténuation

• Atténuation pour Log4j 1.x : Log4j 1.x n'est pas impacté par cette vulnérabilité.

• Atténuation pour Log4j 2.x : Mettre en œuvre l'une des techniques d'atténuation ci-dessous.
• Les utilisateurs de Java 8 (ou d'une version ultérieure) doivent passer à la version 2.16.0.
• Les utilisateurs nécessitant Java 7 doivent effectuer une mise à niveau vers la version 2.12.2 dès qu'elle sera disponible (travail en cours, devrait être disponible bientôt).
• Sinon, supprimez la classe JndiLookup du chemin de classe : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Notez que seul le fichier JAR log4j-core est impacté par cette vulnérabilité. Les applications utilisant uniquement le fichier JAR log4j-api sans le fichier JAR log4j-core ne sont pas impactées par cette vulnérabilité.

Historique

Mesures d'atténuation plus anciennes (discréditées)

Cette page mentionnait précédemment d'autres mesures d'atténuation, mais nous avons découvert que ces mesures ne font que limiter l'exposition tout en laissant certains vecteurs d'attaque ouverts.

Les autres mesures d'atténuation insuffisantes sont les suivantes : définir la propriété système log4j2.formatMsgNoLookups ou la variable d'environnement LOG4J_FORMAT_MSG_NO_LOOKUPS à true pour les versions >= 2.10, ou modifier la configuration de la journalisation pour désactiver les recherches de messages avec %m{nolookups}, %msg{nolookups} ou %message{nolookups} pour les versions >= 2.7 et <= 2.14.1.

La raison pour laquelle ces mesures sont insuffisantes est que, en plus du vecteur d'attaque Thread Context mentionné ci-dessus, il existe encore des chemins de code dans Log4j où des recherches de messages pourraient se produire : des exemples connus sont les applications qui utilisent Logger.printf("%s", userInput), ou les applications qui utilisent une fabrique de messages personnalisée, où les messages résultants n'implémentent pas StringBuilderFormattable. Il peut y avoir d'autres vecteurs d'attaque.

La chose la plus sûre à faire est de mettre à niveau Log4j vers une version sûre, ou de supprimer la classe JndiLookup du jar log4j-core.

Détails de la version

Dans la version 2.12.2, la fonction de consultation des messages a été complètement supprimée. Les recherches dans la configuration fonctionnent toujours. En outre, Log4j désactive désormais l'accès à JNDI par défaut. Les recherches JNDI renvoient désormais une valeur constante. Enfin, Log4j limite désormais les protocoles par défaut à java.

Dans la version 2.16.0, la fonction de consultation des messages a été complètement supprimée. Les recherches dans la configuration fonctionnent toujours. En outre, Log4j désactive désormais l'accès à JNDI par défaut. Les recherches JNDI dans la configuration doivent maintenant être activées explicitement. De plus, Log4j limite désormais les protocoles par défaut à java, ldap et ldaps et limite les protocoles ldap à l'accès aux objets primitifs Java. Les hôtes autres que l'hôte local doivent être explicitement autorisés.

Travaux en cours

L'équipe Log4j continuera à mettre activement à jour cette page (Ndlr : page source) au fur et à mesure que des informations supplémentaires seront connues.

Crédit

Ce problème a été découvert par Kai Mindermann de iC Consult.

Références

https://issues.apache.org/jira/browse/LOG4J2-3221

26 novembre 2021 Corrigé dans Log4j 2.15.0

CVE-2021-44228

CVE-2021-44228 : Les fonctionnalités JNDI d'Apache Log4j2 ne protègent pas contre le contrôle par un attaquant de LDAP et d'autres points de terminaison liés à JNDI.

Gravité

Critique

Score CVSS de base

10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Versions concernées

Toutes les versions de 2.0-beta9 à 2.12.1 et de 2.13.0 à 2.14.1.

Description

Dans les versions d'Apache Log4j2 jusqu'à la version 2.14.1 incluse (à l'exception de la version de sécurité 2.12.2), les fonctionnalités JNDI utilisées dans les configurations, les messages de journal et les paramètres ne sont pas protégées contre le contrôle par un attaquant de LDAP et d'autres points de terminaison liés à JNDI. Un attaquant qui peut contrôler les messages de journal ou les paramètres des messages de journal peut exécuter du code arbitraire chargé à partir de serveurs LDAP lorsque la substitution de recherche de message est activée.

Mesures d'atténuation

Atténuation pour Log4j 1.x : Log4j 1.x ne dispose pas de Lookups, le risque est donc plus faible. Les applications utilisant Log4j 1.x ne sont vulnérables à cette attaque que si elles utilisent JNDI dans leur configuration. Un CVE distinct (CVE-2021-4104) a été déposé pour cette vulnérabilité. Pour y remédier : vérifiez votre configuration de journalisation pour vous assurer qu'aucun JMSAppender n'est configuré. Les configurations Log4j 1.x sans JMSAppender ne sont pas affectées par cette vulnérabilité.

Atténuation pour Log4j 2.x : Mettre en oeuvre l'une des techniques d'atténuation ci-dessous.

• Les utilisateurs de Java 8 (ou d'une version ultérieure) doivent passer à la version 2.16.0.
• Les utilisateurs nécessitant Java 7 doivent effectuer une mise à niveau vers la version 2.12.2 dès qu'elle sera disponible (travail en cours, devrait être disponible bientôt).
• Sinon, supprimez la classe JndiLookup du chemin de classe : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Notez que seul le fichier JAR log4j-core est impacté par cette vulnérabilité. Les applications utilisant uniquement le fichier JAR log4j-api sans le fichier JAR log4j-core ne sont pas impactées par cette vulnérabilité.

Historique

Mesures d'atténuation plus anciennes (discréditées)

Cette page mentionnait précédemment d'autres mesures d'atténuation, mais nous avons découvert que ces mesures ne font que limiter l'exposition tout en laissant certains vecteurs d'attaque ouverts.

Il a été constaté que la version 2.15.0 est toujours vulnérable lorsque la configuration a une disposition de motif contenant un Context Lookup (par exemple, $${ctx:loginId}), ou un motif Thread Context Map %X, %mdc ou %MDC. Lorsqu'un attaquant peut contrôler les valeurs de Thread Context, il peut injecter un motif JNDI Lookup, qui sera évalué et donnera lieu à une connexion JNDI. Log4j 2.15.0 restreint par défaut les connexions JNDI à localhost, mais cela peut encore entraîner des attaques DOS (déni de service), voire pire.

Un nouveau CVE (CVE-2021-45046, voir ci-dessus) a été créé pour ce problème.

Les autres mesures d'atténuation insuffisantes sont les suivantes : définir la propriété système log4j2.formatMsgNoLookups ou la variable d'environnement LOG4J_FORMAT_MSG_NO_LOOKUPS à true pour les versions >= 2.10, ou modifier la configuration de la journalisation pour désactiver les recherches de messages avec %m{nolookups}, %msg{nolookups} ou %message{nolookups} pour les versions >= 2.7 et <= 2.14.1.

La raison pour laquelle ces mesures sont insuffisantes est que, en plus du vecteur d'attaque Thread Context mentionné ci-dessus, il existe encore des chemins de code dans Log4j où des recherches de messages pourraient se produire : des exemples connus sont les applications qui utilisent Logger.printf("%s", userInput), ou les applications qui utilisent une fabrique de messages personnalisée, où les messages résultants n'implémentent pas StringBuilderFormattable. Il peut y avoir d'autres vecteurs d'attaque.

La chose la plus sûre à faire est de mettre à niveau Log4j vers une version sûre, ou de supprimer la classe JndiLookup du jar log4j-core.

Détails de la version

Depuis Log4j 2.15.0, la fonction de consultation des messages est désactivée par défaut. Les recherches dans la configuration fonctionnent toujours. Bien que Log4j 2.15.0 dispose d'une option permettant d'activer les recherches de cette manière, il est fortement déconseillé aux utilisateurs de l'activer. Un mécanisme de liste blanche a été introduit pour les connexions JNDI, autorisant uniquement localhost par défaut.

À partir de la version 2.16.0, la fonction de consultation des messages a été complètement supprimée. Les recherches dans la configuration fonctionnent toujours. De plus, Log4j désactive maintenant l'accès à JNDI par défaut. Les recherches JNDI dans la configuration doivent maintenant être activées explicitement. De plus, Log4j limite désormais les protocoles par défaut à java, ldap et ldaps et limite les protocoles ldap à l'accès aux objets primitifs Java. Les hôtes autres que l'hôte local doivent être explicitement autorisés.

Travaux en cours

L'équipe Log4j continuera à mettre activement à jour cette page au fur et à mesure que des informations supplémentaires seront connues.

Crédit

Ce problème a été découvert par Chen Zhaojun de l'équipe de sécurité d'Alibaba Cloud.

Références

https://issues.apache.org/jira/browse/LOG4J2-3201 et https://issues.apache.org/jira/browse/LOG4J2-3198.