È stata scoperta un'altra vulnerabilità nella libreria Log4j 2 (CVE-2021-45105), che, a differenza delle due precedenti, è stata classificata come pericolosa, ma non critica. Il nuovo problema consente di causare un'interruzione del servizio e si manifesta attraverso cicli infiniti e crash durante l'elaborazione di determinate stringhe. La vulnerabilità è stata rimossa nella versione di Log4j 2.17 pubblicata poche ore fa. La gravità della vulnerabilità è attenuata dal fatto che il problema si verifica solo sui sistemi con Java 8.
Sono vulnerabili i sistemi che utilizzano richieste contestuali (Context Lookup) per determinare il formato dell'output del log, come ${ctx:var}. Nelle versioni di Log4j da 2.0-alpha1 a 2.16.0, mancava una protezione contro la ricorsione incontrollata, permettendo a un attaccante, tramite manipolazione del valore utilizzato per la sostituzione, di causare cicli infiniti che portano all'esaurimento dello spazio nello stack e al crash del processo. In particolare, il problema si verificava con valori di sostituzione come «${${::-${::-$${::-j}}}}».
Inoltre, i ricercatori di Blumira hanno proposto un metodo di attacco contro le applicazioni Java vulnerabili che non accettano richieste di rete esterne. Questo tipo di attacco può colpire i sistemi degli sviluppatori o degli utenti di applicazioni Java. Il fulcro del metodo è che, se sul sistema dell'utente ci sono processi Java vulnerabili che accettano connessioni solo dall'host locale (localhost) o che gestiscono richieste RMI (Remote Method Invocation, porta 1099), l'attacco può essere eseguito tramite codice JavaScript che viene eseguito aprendo una pagina malevola nel browser dell'utente. Per stabilire una connessione con la porta di rete dell'applicazione Java durante un attacco simile, si utilizza l'API WebSocket, la quale, a differenza delle richieste HTTP, non è soggetta a restrizioni same-origin (WebSocket può anche essere utilizzato per scansionare le porte di rete sull'host locale per identificare i gestori di rete disponibili).
Inoltre, sono interessanti i risultati della valutazione delle vulnerabilità delle librerie con dipendenze da Log4j pubblicati da Google. Secondo Google, il problema riguarda l'8% di tutti i pacchetti nel repository di Maven Central. In particolare, 35863 pacchetti Java, con dipendenze dirette e indirette da Log4j, sono risultati vulnerabili. Log4j viene utilizzato come dipendenza diretta di primo livello solo nel 17% dei casi, mentre nell'83% dei pacchetti vulnerabili la connessione avviene tramite pacchetti intermedi dipendenti da Log4j, ovvero dipendenze di secondo e di livello superiore (21% — di secondo livello, 12% — di terzo, 14% — di quarto, 26% — di quinto, 6% — di sesto). I ritmi di correzione delle vulnerabilità lasciano ancora a desiderare, una settimana dopo l'identificazione della vulnerabilità, solo in 4620 dei 35863 pacchetti identificati il problema è stato risolto, ovvero nel 13%.
Nel frattempo, l'Agenzia per la cybersicurezza e la protezione delle infrastrutture degli Stati Uniti ha pubblicato un'ordinanza d'emergenza che obbliga le agenzie federali a identificare i sistemi informatici vulnerabili a Log4j e a installare gli aggiornamenti necessari per bloccare il problema entro il 23 dicembre. Entro il 28 dicembre, le organizzazioni devono relazionare sul lavoro svolto. È stata preparata una lista di prodotti in cui è stata confermata la vulnerabilità (la lista include oltre 23.000 applicazioni).
Fonte: opennet.ru
