Un'altra vulnerabilità è stata identificata 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 causare un rifiuto di servizio e si manifesta sotto forma di loop e arresti anomali durante l'elaborazione di determinate righe. La vulnerabilità è stata risolta nella versione Log4j 2.17 rilasciata poche ore fa. Il pericolo della vulnerabilità è mitigato dal fatto che il problema si presenta solo su sistemi con Java 8.
La vulnerabilità colpisce i sistemi che utilizzano query contestuali (Ricerca di contesto), come ${ctx:var}, per determinare il formato di output del registro. Le versioni di Log4j dalla 2.0-alpha1 alla 2.16.0 mancavano di protezione contro la ricorsione incontrollata, il che consentiva a un utente malintenzionato di manipolare il valore utilizzato nella sostituzione per causare un loop, portando all'esaurimento dello spazio nello stack e a un arresto anomalo. In particolare, il problema si verificava durante la sostituzione di valori come "${${::-${::-$${::-j}}}}".
Va notato inoltre che i ricercatori di Blumira hanno proposto la possibilità di attaccare applicazioni Java vulnerabili che non accettano richieste di rete esterne; in questo modo possono ad esempio essere attaccati i sistemi degli sviluppatori o degli utenti di applicazioni Java. L'essenza del metodo è che se sul sistema dell'utente sono presenti processi Java vulnerabili che accettano connessioni di rete solo dall'host locale o elaborano richieste RMI (Remote Method Invocation, porta 1099), l'attacco può essere effettuato tramite codice JavaScript eseguito quando gli utenti aprono una pagina dannosa nel proprio browser. Per stabilire una connessione alla porta di rete di un'applicazione Java durante un simile attacco, viene utilizzata l'API WebSocket alla quale, a differenza delle richieste HTTP, non vengono applicate restrizioni sulla stessa origine (WebSocket può essere utilizzato anche per scansionare le porte di rete sulla rete locale host per determinare i gestori di rete disponibili).
Interessanti anche i risultati pubblicati da Google sulla valutazione della vulnerabilità delle librerie associate alle dipendenze Log4j. Secondo Google, il problema riguarda l'8% di tutti i pacchetti presenti nel repository Maven Central. In particolare, sono stati esposti a vulnerabilità 35863 pacchetti Java associati a Log4j tramite dipendenze dirette e indirette. Allo stesso tempo, Log4j viene utilizzato come dipendenza diretta di primo livello solo nel 17% dei casi e nell'83% dei pacchetti interessati l'associazione viene effettuata tramite pacchetti intermedi che dipendono da Log4j, ad es. dipendenze di secondo e superiore livello (21% - secondo livello, 12% - terzo, 14% - quarto, 26% - quinto, 6% - sesto). Il ritmo con cui viene risolta la vulnerabilità lascia ancora molto a desiderare; una settimana dopo l'identificazione della vulnerabilità, su 35863 pacchetti identificati, il problema è stato finora risolto solo in 4620, ovvero al 13%.
Nel frattempo, la Cybersecurity and Infrastructure Protection Agency degli Stati Uniti ha emesso una direttiva di emergenza che impone alle agenzie federali di identificare i sistemi informativi interessati dalla vulnerabilità Log4j e di installare aggiornamenti che blocchino il problema entro il 23 dicembre. Entro il 28 dicembre le organizzazioni sono tenute a riferire sul proprio lavoro. Per semplificare l'identificazione dei sistemi problematici, è stato preparato un elenco di prodotti per i quali è stata confermata la presenza di vulnerabilità (l'elenco comprende più di 23mila applicazioni).
Fonte: opennet.ru