Secondo gli esperti di sicurezza informatica (inclusa la statunitense CISA), la vulnerabilità sulla libreria log4j è uno dei difetti software più gravi mai visti e il motivo è presto detto: sono proprio i progetti software gestiti da volontari come log4j che mantengono Internet in funzione e un loro malfunzionamento o, per l’appunto, una vulnerabilità non risolta, rappresentano un rischio non sostenibile.
In particolare, nel caso di log4j, ciò che caratterizza come dirompente l’attacco che consegue da questa vulnerabilità, come abbiamo già avuto modo di analizzare, è proprio la facilità di sfruttamento da parte di attori malintenzionati e l’infinita popolarità che questa libreria ha guadagnato nel tempo, in tutto il mondo e in tutti i settori dello sviluppo software.
Il bug Log4J minaccia mezza internet: ecco il fix urgente per le aziende
Indice degli argomenti
Il progetto log4j e il software open source
Log4j nasce come progetto open source da un team di sviluppatori volontari dell’Apache Software Foundation che lo hanno ideato, testato e diffuso. Diffondendone appunto, come da fondamento del paradigma open source, anche il codice sorgente, liberamente accessibile e modificabile da chiunque abbia necessità di implementarlo o personalizzarlo per le proprie necessità (non per forza coincidenti con quelle di coloro che hanno ideato il progetto originariamente).
E proprio mentre il team di volontari di Apache rilascia, il 18 dicembre scorso, la terza patch per il fix dell’ultima vulnerabilità rimasta finora irrisolta, CVE-2021-45105 (7,5 sulla scala di gravità CVSS), in molti con commenti, interviste e tweets iniziano a sottolineare i “pericoli” del software open source.
Quando si evidenzia la caratteristica di un software di essere open source, stiamo identificando precisamente il rapporto legale sull’utilizzo di quel software da parte di terzi (il contratto o più semplicemente la licenza d’uso).
Tra tutte le licenze, quelle che sfruttano il paradigma open source sono considerate le “più permissive” nei confronti delle libertà che offrono alle terze persone con cui entrano in contatto: prima fra tutte la possibilità di accedere, modificare, implementare e ridistribuire il codice sorgente con il quale quel software è stato scritto.
Questo concetto è uno tra i più significativi nel mondo della tecnologia e dello sviluppo software a favore di un benessere per la comunità (che decide di adoperare quel prodotto) ma, storicamente, è sempre stato oggetto di travisamenti economici.
Quello che viene etichettato come open source, infatti, non è sempre catalogabile come gratuito. Nella concezione comune invece è proprio così.
Log4j è stato concepito come open source e distribuito gratuitamente a chiunque ne avesse avuto necessità per lo sviluppo di altri progetti, tutto grazie al lavoro volontario (quindi non retribuito) di persone con le capacità che log4j richiedeva.
Nel tempo il prodotto si è diffuso, è stato via via adottato dai più grandi colossi del software e della tecnologia in generale (Microsoft, Google, Twitter e iCloud di Apple usano log4j per i loro prodotti commerciali), senza che nessuno si interessasse veramente ad esso.
Nessuno, nell’ampio panorama di Internet e dello sviluppo web, si è mai interessato (log4j esiste dal lontano 8 gennaio 2001) di come venga mantenuto questo progetto, se fosse il caso di dare una mano al suo sviluppo, se non per scaricarlo, quantomeno per implementarlo nei propri progetti milionari e dimenticarsene.
La vulnerabilità in log4j e i rischi dell’open source
Il vero problema della cyber security su questa vulnerabilità non è il fatto che ci si possa fidare o meno di un software open source: il grande problema reale è come si possa pensare di basare il proprio lavoro (concepito per produrre ed essere remunerativo) su “pezzi” di tecnologia offerti dallo sforzo di una comunità, senza entrare nel merito di come quel lavoro è stato svolto, per quali scopi nasce e quanto può durare così come è stato concepito.
Sono passati 20 anni da quando log4j è stata rilasciata: per quanto sia stato il frutto volontario di esperti, non è di sicuro una buona idea pensare che chiunque possa “regalarci” tutto il proprio sapere e la propria esperienza, nel momento in cui serve ci serve, sempre pronta e aggiornata per 20 anni.
Il problema di elevato impatto globale che log4j ha generato con la sua vulnerabilità, forse poteva essere evitato se un consorzio di colossi della tecnologia (accomunati dal fatto che la utilizzavano) si fosse messo in campo, unendo le proprie forze (esperienziali ma anche economiche), per verificare a che livello di sviluppo fosse la libreria così tanto diffusa nei prodotti utilizzati per produrre profitto.
Inoltre, oggi parliamo di log4j ma è doveroso ricordare l’importanza dell’open source nel mondo della tecnologia. Questo stesso problema, infatti, impatta (o potrebbe impattare in futuro) in un elevato insieme di applicazioni (o librerie stesse), oggi risultato di contributi volontari di una comunità.
Internet stesso è stato concepito su tecnologia open source, la maggior parte dei server che ospitano i siti web che visitiamo sono basati su software open source (GNU/Linux per il sistema operativo e Apache per il web server).
Cosa impariamo dalla vulnerabilità in log4j
Gran parte del software che fa funzionare i router delle nostre connessioni Internet sono basati su Linux, oppure le parti fondamentali su cui sono fondati i software di Facebook e Google utilizzano contributi open source (Android è una distribuzione derivata del progetto GNU/Linux).
Molti linguaggi di programmazione stessi, con i quali vengono scritti i software che utilizziamo, sono open source e infine tutta una serie immensa di librerie utili agli scopi più diversi, proprio come il caso di log4j.
Esistono anche molti esempi già virtuosi di questo meccanismo appena citato nei quali, infatti, proprio determinati colossi della tecnologia hanno investito in progetti open source, al fine di migliorarne la sicurezza e mantenerne efficiente il ciclo di sviluppo: la popolare distribuzione GNU/Linux Ubuntu è sotto l’ala protettiva della società privata Canonical Ltd, che con investimenti e personale remunerato ne monitora lo sviluppo (benché open source e accessibile a chiunque).
Ma esistono anche purtroppo troppi e troppo diffusi esempi di tecnologia open source, prodotta volontariamente per il bene di una comunità, implementati in giganteschi progetti altamente produttivi (in termini di guadagno economico), senza il minimo riconoscimento alcuno e dai quali si pretende puntuale efficienza e sicurezza.
È quindi arrivato il momento di ripensare il rapporto che i grandi della tecnologia hanno nel ciclo di sviluppo di un progetto tecnologico, tenendo conto di tutte le parti che si mettono in gioco, per la cyber sicurezza della propria infrastruttura e di tutti gli utenti.
Reinventare la ruota ogni volta che abbiamo necessità di fabbricare un’auto non è mai una buona idea, ma fare ricerca sull’invenzione della ruota al fine di migliorarla è doveroso per chiunque si occupi di sicurezza tecnologica.
