{"id":102661,"date":"2021-12-19T03:36:43","date_gmt":"2021-12-19T01:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov"},"modified":"2021-12-19T03:36:43","modified_gmt":"2021-12-19T01:36:45","slug":"eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov","title":{"rendered":"Un'altra vulnerabilit\u00e0 in Log4j 2. I problemi in Log4j interessano l'8% dei pacchetti Maven","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
\u00c8 stata identificata un'altra vulnerabilit\u00e0 nella libreria Log4j 2 (CVE-2021-45105), che a differenza dei due problemi precedenti, \u00e8 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\u00e0 \u00e8 stata corretta nella versione di Log4j 2.17 pubblicata poche ore fa. Il rischio della vulnerabilit\u00e0 \u00e8 ridotto dal fatto che il problema si verifica solo sui sistemi con Java 8. <\/p>\n
Le vulnerabilit\u00e0 colpiscono i sistemi che utilizzano query contestuali (Context Lookup) per determinare il formato di output nei log, come ${ctx:var}. Nelle versioni di Log4j, dalla 2.0-alpha1 alla 2.16.0, mancava la protezione contro la ricorsione incontrollata, che consentiva a un attaccante, manipolando il valore utilizzato per la sostituzione, di provocare un loop, portando all'esaurimento dello spazio nello stack e alla chiusura anomala del processo. In particolare, il problema si verificava quando venivano utilizzati valori come «${${::-${::-$${::-j}}}}». <\/p>\n
Si pu\u00f2 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, \u00e8 possibile attaccare in questo modo i sistemi degli sviluppatori o degli utenti di applicazioni Java. Il punto del metodo \u00e8 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\u00f2 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\u00f2 anche essere utilizzato per la scansione delle porte di rete sull'host locale al fine di identificare i gestori di rete disponibili).
<\/center> <\/p>\n
Risultano interessanti anche i risultati di valutazione delle vulnerabilit\u00e0 delle librerie correlate a Log4j pubblicati da Google. Secondo Google, il problema colpisce l'8% di tutti i pacchetti nel repository Maven Central. In particolare, 35.863 pacchetti Java, correlati a Log4j tramite dipendenze dirette e indirette, si sono rivelati vulnerabili. In questo caso, Log4j \u00e8 utilizzato come dipendenza diretta di primo livello solo nel 17% dei casi, mentre nell'83% dei pacchetti colpiti dalla vulnerabilit\u00e0, il legame avviene tramite pacchetti intermedi che dipendono da Log4j, ovvero dipendenze di secondo e livello superiore (21% - secondo livello, 12% - terzo, 14% - quarto, 26% - quinto, 6% - sesto). I tempi di risoluzione delle vulnerabilit\u00e0 lasciano ancora a desiderare; una settimana dopo la scoperta, il problema \u00e8 stato risolto solo in 4.620 dei 35.863 pacchetti identificati, ovvero nel 13%.
<\/center> <\/p>\n
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 \u00e8 stata preparata una lista di prodotti in cui \u00e8 stata confermata la presenza della vulnerabilit\u00e0 (nella lista ci sono oltre 23.000 applicazioni). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Un'altra](\"\/wp-content\/uploads\/2021\/12\/811931e8c3ae3f3f3c2e81db361034e6.jpg\")
<\/center> <\/p>\n![\"Un'altra](\"\/wp-content\/uploads\/2021\/12\/1e61b09923c7e055fa635545f1b3de6b.jpg\")
<\/center> <\/p>\n