tejas-nagchandi/cve-2021-45046Réplication de CVE-2021-45046
Il a été constaté que le correctif apporté à CVE-2021-44228 dans Apache Log4j 2.15.0 était incomplet dans certaines configurations non par défaut. Cela pourrait permettre à des attaquants ayant le contrôle des données d'entrée du 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}) soit un motif de Thread Context Map (%X, %mdc, ou %MDC), de créer des données d'entrée malveillantes à l'aide d'un motif JNDI Lookup, entraînant une attaque par déni de service (DOS). Log4j 2.15.0 fait de son mieux pour restreindre par défaut les recherches LDAP JNDI à localhost. Log4j 2.16.0 corrige ce problème en supprimant la prise en charge des motifs de recherche de messages et en désactivant la fonctionnalité JNDI par défaut.
Log4j a introduit le concept de Mapped Diagnostic Context (contexte de diagnostic mappé), ou MDC.
Log4j 2 poursuit avec l'idée du MDC et du NDC, mais les fusionne en un seul Thread Context. Le Thread Context Map est l'équivalent du MDC et le Thread Context Stack est l'équivalent du NDC. Bien qu'ils soient souvent utilisés à d'autres fins que le diagnostic de problèmes, ils sont toujours fréquemment appelés MDC et NDC dans Log4j 2, car ils sont déjà bien connus sous ces acronymes.
La plupart des systèmes réels doivent gérer plusieurs clients simultanément. Dans une implémentation multithread typique d'un tel système, différents threads gèrent différents clients. La journalisation est particulièrement adaptée pour tracer et déboguer des applications distribuées complexes. Une approche courante pour différencier la sortie de journalisation d'un client par rapport à une autre consiste à instancier un nouveau logger distinct pour chaque client. Cela favorise la prolifération des loggers et augmente la charge de gestion de la journalisation.
Une technique plus légère consiste à marquer de manière unique chaque requête de journalisation initiée à partir de la même interaction client. Neil Harrison a décrit cette méthode dans le livre « Patterns for Logging Diagnostic Messages », dans Pattern Languages of Program Design 3, édité par R. Martin, D. Riehle et F. Buschmann (Addison-Wesley, 1997). Tout comme un poisson peut être étiqueté et suivi dans ses déplacements, marquer les événements de journalisation avec une étiquette commune ou un ensemble d'éléments de données permet de suivre le flux complet d'une transaction ou d'une requête. Nous appelons cela l'étiquetage des poissons (Fish Tagging).
Log4j fournit deux mécanismes pour réaliser l'étiquetage des poissons ; le Thread Context Map et le Thread Context Stack. Le Thread Context Map permet d'ajouter un nombre illimité d'éléments et de les identifier à l'aide de paires clé/valeur. Le Thread Context Stack permet de placer un ou plusieurs éléments sur la pile, puis de les identifier par leur ordre dans la pile ou par les données elles-mêmes. Étant donné que les paires clé/valeur sont plus flexibles, le Thread Context Map est recommandé lorsque des éléments de données peuvent être ajoutés pendant le traitement de la requête ou lorsqu'il y a plus d'un ou deux éléments.
Pour marquer de manière unique chaque requête à l'aide du Thread Context Stack, l'utilisateur place des informations contextuelles sur la pile.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 https://logging.apache.org/log4j/2.x/manual/thread-context.html
