Qualche settimana fa la notizia dei problemi di sicurezza di Log4j stavano mettendo sottosopra molti utenti della rete ed è che si tratta di una delle falle più sfruttate e che molti esperti hanno etichettato come «la più pericolosa in un molto tempo», Delle vulnerabilità che sono state rese note in rete ne parliamo alcune qui sul blog e questa volta abbiamo trovato la notizia di un altro.
Ed è che pochi giorni fa è stata rilasciata la notizia che un'altra vulnerabilità è stata identificata nella libreria Log4j 2 (che è già elencato sotto CVE-2021-45105) e che, a differenza dei due precedenti problemi, è stato classificato come pericoloso, ma non critico.
Il nuovo problema consente una negazione del servizio e si manifesta sotto forma di loop e terminazioni anomale durante l'elaborazione di determinate linee.
Vulnerabilità interessa i sistemi che utilizzano la ricerca contestuale, come $ {ctx: var}, per determinare il formato di output del registro.
Le Le versioni di Log4j dalla 2.0-alpha1 alla 2.16.0 non avevano protezione contro la ricorsione incontrollataQuali ha permesso a un utente malintenzionato di manipolare il valore utilizzato in sostituzione per causare un ciclo infinito che esaurirebbe lo spazio nello stack e causerebbe il blocco del processo. In particolare, il problema si è verificato durante la sostituzione di valori come "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Inoltre, Si può notare che i ricercatori Blumira hanno proposto un attacco alle applicazioni Java vulnerabili che non accettano richieste da reti esterne, ad esempio, possono essere attaccati in questo modo sistemi di sviluppatori o utenti di applicazioni Java.
L'essenza del metodo è che se ci sono processi Java vulnerabili sul sistema dell'utente che accetta connessioni di rete solo dall'host locale (localhost) o elabora richieste RMI (Remote Method Invocation, porta 1099), l'attacco può essere eseguito tramite codice JavaScript eseguito quando l'utente apre una pagina dannosa nel browser. Per stabilire una connessione alla porta di rete di un'applicazione Java in un tale 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 sul host per determinare i driver di rete disponibili).
Interessanti anche i risultati della valutazione della vulnerabilità delle librerie associate alle dipendenze con Log4j pubblicati da Google. Secondo Google, il problema interessa l'8% di tutti i pacchetti nel repository Maven Central.
In particolare, sono stati esposti a vulnerabilità 35863 pacchetti Java relativi a Log4j con dipendenze dirette e indirette. Log4j a sua volta viene utilizzato come dipendenza diretta di primo livello solo nel 17% dei casi, e nell'83% dei pacchetti coperti dalla vulnerabilità il binding avviene tramite pacchetti intermedi che dipendono da Log4j, ovvero tell. dipendenze di secondo e più alto livello (21% - il secondo livello, 12% - il terzo, 14% - il quarto, 26% - il quinto, 6% - il sesto).
Il ritmo di riparazione della vulnerabilità lascia ancora molto a desiderare, una settimana dopo l'identificazione della vulnerabilità, su 35863 pacchetti identificati, il problema è stato risolto finora solo in 4620, cioè al 13%.
Le modifiche ai pacchetti sono necessarie per aggiornare i requisiti di dipendenza e sostituire i collegamenti della vecchia versione con versioni fisse di Log4j 2 (i pacchetti Java praticano l'associazione a una versione specifica e non un intervallo aperto che consente l'installazione della versione più recente).
L'eliminazione della vulnerabilità nelle applicazioni Java è ostacolata dal fatto che spesso i programmi includono una copia delle librerie in consegna e non è sufficiente aggiornare la versione Log4j 2 nei pacchetti di sistema.
Nel frattempo, l'Agenzia degli Stati Uniti per la protezione delle infrastrutture e la sicurezza informatica ha emesso una direttiva di emergenza che richiede alle agenzie federali di identificare i sistemi informativi interessati dalla vulnerabilità di Log4j e installare aggiornamenti che bloccano il problema prima del 23 dicembre.
È stata invece data una linea guida fino al 28 dicembre, in cui le organizzazioni avevano l'obbligo di riferire sul lavoro svolto. Per semplificare l'individuazione dei sistemi problematici, è stato predisposto un elenco di prodotti in cui è stata confermata la manifestazione di una vulnerabilità (sono oltre 23mila le applicazioni in elenco).
Infine, Vale la pena ricordare che la vulnerabilità è stata risolta in Log4j 2.17 che è stato pubblicato pochi giorni fa e agli utenti che hanno gli aggiornamenti disabilitati si consiglia di effettuare l'aggiornamento corrispondente, oltre al fatto che il pericolo della vulnerabilità è mitigato dal fatto che il problema si manifesta solo su sistemi con Java 8.
fonte: https://logging.apache.org/