A tre mesi dalla scoperta della vulnerabilità Lo4j [CVE-2021-44228] e dalla pubblicazione della patch, più di 4 download su 10 continuano a riguardare versioni fallate. Il dato emerge dalla piattaforma di Sonatype, che gestisce il più grande repository al mondo di componenti open source tramite la sua piattaforma Central. La sua dashboard rivela che il 41% dei pacchetti Log4j scaricati tra il 4 febbraio e il 10 marzo 2022 sono versioni precedenti alla Log4j 2.15.0.

Quest'ultima, per chi non lo ricordasse, è la versione che beneficia della prima patch per la correzione della principale falla Log4Shell. Per avere dei numeri su cui ragionare, il download di Log4J dal 10 dicembre 2021 sono stati complessivamente oltre 31,4 milioni, di cui quelli fallati potrebbero essere all'incirca 10 milioni.

I numeri conferma quanto detto a suo tempo dagli esperti: per liberarci di questa falla serviranno anni. il problema non è la distrazione degli sviluppatori, quando l'uso massivo di sistemi di compilazione automatizzati, che sono configurati per scaricare una versione specifica delle loro dipendenze. Se non c'è stata una manutenzione puntuale di tali sistemi e non sono state cambiate le loro dipendenze, continueranno a scaricare una versione antecedente a quella corretta.

L'impostazione su una particolare release, peraltro, non è rara: si fa spesso per evitare conflitti che potrebbero essere generati dal software aggiornato e non testato. Molti software dipendono dalle versioni vulnerabili di Log4j e rimuoverli improvvisamente potrebbe causare il blocco di tali sistemi. E non aiuta il fatto che Log4j sia spesso sepolto sotto a svariati diversi livelli di profondità delle applicazioni Java, non facilitando la propria scoperta, anzi, allungando anche di molto i tempi di scoperta e correzione.

È proprio la mancanza di consapevolezza a ostacolare la bonifica dei sistemi vulnerabili. In assenza di visibilità e di conoscenza profonda dei sistemi, infatti, molte aziende stanno ancora cercando di costruire il proprio inventario software, quindi non hanno ancora preso provvedimenti che sulla carta avrebbero dovuto essere urgenti. La situazione è confermata anche dai dati recenti pubblicati da Qualys, secondo cui circa il 30% delle istanze Log4j su Internet rimane ancora vulnerabile all'exploit.

Il problema riguarda anche Maven Central. Un'analisi dei ricercatori di Google che risale alla settimana successiva alla divulgazione della vulnerabilità Log4Shell aveva mostrato che circa 17.000 pacchetti Java su Maven Central erano fallati. Secondo le stime di Google, il problema riguardava il 25% dei pacchetti. Da allora, è probabile che molti altri siano stati corretti, ma difficilmente lo sono stati tutti.

Il guaio è che le versioni fallate non si possono rimuovere tout court perché, come spiegano i gestori di Maven Central, se improvvisamente rimuovessero tutte le vecchie versioni di Log4j dal repository, ogni build in tutto il mondo che va a cercarla andrebbe in blocco. Per far comprendere la questione, c'è un precedente che risale al 2016. Un programmatore rimosse dal registro JavaScript npm un pacchetto che aveva sviluppato, e che era oggetto di controversia. Conteneva solo 11 righe di codice, ma la sua rimozione interruppe migliaia di progetti e causò notevoli interruzioni su Internet.