È stata identificata un'altra vulnerabilità nella libreria Log4j 2 (CVE-2021-45105), che a differenza dei due problemi precedenti, è classificata come pericolosa, ma non critica. Il nuovo problema consente di provocare un'interruzione del servizio e si manifesta come un ciclo infinito e un arresto anomalo nella gestione di determinate stringhe. La vulnerabilità è stata corretta nella versione di Log4j 2.17 pubblicata poche ore fa. Il rischio della vulnerabilità è ridotto dal fatto che il problema si verifica solo sui sistemi con Java 8.
I sistemi vulnerabili sono quelli che utilizzano richieste contestuali (Context Lookup) per determinare il formato di output nel log, come ${ctx:var}. Nelle versioni di Log4j, dalla 2.0-alpha1 fino alla 2.16.0, non c'era protezione contro la ricorsione incontrollata, il che consentiva a un attaccante, tramite manipolazioni del valore utilizzato per il subsituzione, di provocare un ciclo infinito, portando all'esaurimento dello spazio nello stack e all'arresto anomalo del processo. In particolare, il problema si verificava durante la sostituzione di valori come «${${::-${::-$${::-j}}}}».
Si può anche osservare che i ricercatori dell'azienda Blumira hanno proposto un'opzione di attacco per le applicazioni Java vulnerabili che non accettano richieste di rete esterne; per esempio, è possibile attaccare in questo modo i sistemi degli sviluppatori o degli utenti di applicazioni Java. Il punto del metodo è che, se sul sistema dell'utente ci sono processi Java vulnerabili che accettano connessioni di rete solo dall'host locale (localhost), o che gestiscono richieste RMI (Remote Method Invocation, porta 1099), l'attacco può essere effettuato tramite codice JavaScript eseguito quando gli utenti aprono una pagina dannosa nel browser. Per stabilire una connessione con la porta di rete dell'applicazione Java durante un attacco di questo tipo si utilizza l'API WebSocket, a differenza delle richieste HTTP, a cui non si applicano le restrizioni same-origin (il WebSocket può anche essere utilizzato per la scansione delle porte di rete sull'host locale al fine di identificare i gestori di rete disponibili).
Fanno anche notizia i risultati della valutazione delle vulnerabilità delle librerie pubblicati da Google, relativi alle dipendenze con Log4j. Secondo Google, il problema riguarda l'8% di tutti i pacchetti nel repository Maven Central. In particolare, 35863 pacchetti Java legati a Log4j risultano vulnerabili a dipendenze dirette e indirette. In questo caso, Log4j viene utilizzato come dipendenza diretta di primo livello solo nel 17% dei casi, mentre nell'83% dei pacchetti colpiti la connessione avviene tramite pacchetti intermedi che dipendono da Log4j, ossia dipendenze di secondo e di livello superiore (21% - secondo livello, 12% - terzo, 14% - quarto, 26% - quinto, 6% - sesto). I tempi di correzione delle vulnerabilità lasciano a desiderare, a una settimana dalla scoperta della vulnerabilità, da 35863 pacchetti identificati, il problema è stato risolto solo per 4620, ossia il 13%.
Nel frattempo, l'Agenzia per la sicurezza informatica e la protezione delle infrastrutture degli Stati Uniti ha pubblicato una direttiva urgente che obbliga le agenzie federali a identificare i sistemi informatici vulnerabili a Log4j e a installare gli aggiornamenti per bloccare il problema entro il 23 dicembre. Entro il 28 dicembre, le organizzazioni sono tenute a relazionare sul lavoro svolto. Per semplificare l'individuazione dei sistemi problematici è stata preparata una lista di prodotti in cui è stata confermata la presenza della vulnerabilità (nella lista ci sono oltre 23.000 applicazioni).
Fonte: opennet.ru
