tejas-nagchandi/cve-2021-45046Replica di CVE-2021-45046
È stato riscontrato che la correzione per CVE-2021-44228 in Apache Log4j 2.15.0 era incompleta in alcune configurazioni non predefinite. Ciò potrebbe consentire ad attaccanti con controllo sui dati di input del Thread Context Map (MDC) di creare dati di input dannosi utilizzando un pattern JNDI Lookup, quando la configurazione di logging utilizza un Pattern Layout non predefinito con un Context Lookup (ad esempio, $${ctx:loginId}) o un pattern Thread Context Map (%X, %mdc, o %MDC), con conseguente attacco di denial of service (DOS). Log4j 2.15.0 tenta al meglio delle sue possibilità di limitare le lookup JNDI LDAP a localhost per impostazione predefinita. Log4j 2.16.0 risolve il problema rimuovendo il supporto per i pattern di lookup dei messaggi e disabilitando la funzionalità JNDI per impostazione predefinita.
Log4j ha introdotto il concetto di Mapped Diagnostic Context, o MDC.
Log4j 2 prosegue con l'idea di MDC e NDC, ma le fonde in un unico Thread Context. La Thread Context Map è l'equivalente di MDC, mentre la Thread Context Stack è l'equivalente di NDC. Sebbene questi elementi siano spesso utilizzati per scopi diversi dalla diagnosi dei problemi, vengono ancora frequentemente chiamati MDC e NDC in Log4j 2, poiché sono già ben noti con questi acronimi.
La maggior parte dei sistemi reali deve gestire più client contemporaneamente. In una tipica implementazione multithread di un tale sistema, thread diversi gestiscono client diversi. Il logging è particolarmente adatto per tracciare e fare debug di applicazioni distribuite complesse. Un approccio comune per distinguere l'output di logging di un client da un altro è istanziare un nuovo logger separato per ciascun client. Questo favorisce la proliferazione dei logger e aumenta il sovraccarico di gestione del logging.
Una tecnica più leggera è contrassegnare in modo univoco ogni richiesta di log originata dalla stessa interazione del client. Neil Harrison descrisse questo metodo nel libro "Patterns for Logging Diagnostic Messages", in Pattern Languages of Program Design 3, a cura di R. Martin, D. Riehle e F. Buschmann (Addison-Wesley, 1997). Proprio come un pesce può essere marcato e i suoi movimenti tracciati, contrassegnare gli eventi di log con un tag comune o un insieme di elementi di dati consente di tracciare l'intero flusso di una transazione o di una richiesta. Chiamiamo questa tecnica Fish Tagging (marcatura dei pesci).
Log4j fornisce due meccanismi per eseguire il Fish Tagging: la Thread Context Map e la Thread Context Stack. La Thread Context Map consente di aggiungere un numero qualsiasi di elementi e identificarli tramite coppie chiave/valore. La Thread Context Stack consente di inserire uno o più elementi nello Stack e poi identificarli in base al loro ordine nello Stack o ai dati stessi. Poiché le coppie chiave/valore sono più flessibili, la Thread Context Map è consigliata quando gli elementi di dati possono essere aggiunti durante l'elaborazione della richiesta o quando gli elementi sono più di uno o due.
Per contrassegnare in modo univoco ogni richiesta utilizzando la Thread Context Stack, l'utente inserisce informazioni contestuali nello Stack.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 https://logging.apache.org/log4j/2.x/manual/thread-context.html
