{"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 scoperta un'altra vulnerabilit\u00e0 nella libreria Log4j 2 (CVE-2021-45105), che, a differenza delle due precedenti, \u00e8 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\u00e0 \u00e8 stata rimossa nella versione di Log4j 2.17 pubblicata poche ore fa. La gravit\u00e0 della vulnerabilit\u00e0 \u00e8 attenuata dal fatto che il problema si verifica solo sui sistemi con Java 8. <\/p>\n
Le vulnerabilit\u00e0 colpiscono i sistemi che utilizzano richieste contestuali (Context Lookup) per determinare il formato di output nei log, come ${ctx:var}. Nelle versioni di Log4j, dalla 2.0-alpha1 fino alla 2.16.0, non era presente una protezione contro la ricorsione incontrollata, permettendo cos\u00ec a un attaccante, manipolando il valore utilizzato per la sostituzione, di innescare un ciclo che portava all'esaurimento dello spazio dello stack e alla terminazione del processo. In particolare, il problema si presentava quando si sostituivano valori come «${${::-${::-$${::-j}}}}». <\/p>\n
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\u00f2 colpire i sistemi degli sviluppatori o degli utenti di applicazioni Java. Il fulcro del metodo \u00e8 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\u00f2 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 \u00e8 soggetta a restrizioni same-origin (WebSocket pu\u00f2 anche essere utilizzato per scansionare le porte di rete sull'host locale per identificare i gestori di rete disponibili).
<\/center> <\/p>\n
Interessanti anche i risultati della valutazione delle vulnerabilit\u00e0 delle librerie pubblicati da Google in relazione alle dipendenze di Log4j. Secondo Google, il problema riguarda l'8% di tutti i pacchetti nel repository di Maven Central. In particolare, 35863 pacchetti Java correlati a Log4j sono risultati vulnerabili, sia per dipendenze dirette che indirette. Log4j viene utilizzato come dipendenza diretta di primo livello solo nel 17% dei casi, mentre nell'83% dei pacchetti vulnerabili l'associazione avviene tramite pacchetti intermedi che dipendono da Log4j, ossia dipendenze di secondo e di livello superiore (21% di secondo livello, 12% di terzo, 14% di quarto, 26% di quinto, 6% di sesto). Il tasso di risoluzione di queste vulnerabilit\u00e0 lascia ancora a desiderare; una settimana dopo la scoperta della vulnerabilit\u00e0, solo 4620 dei 35863 pacchetti identificati hanno risolto il problema, cio\u00e8 il 13%.
<\/center> <\/p>\n
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. \u00c8 stata preparata una lista di prodotti in cui \u00e8 stata confermata la vulnerabilit\u00e0 (la lista include 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