Google ha attribuito un nuovo ID CVE a una vulnerabilità di sicurezza di libwebp sfruttata come zero-day negli attacchi e patchata due settimane fa.
L’azienda aveva inizialmente rivelato la falla come una debolezza di Chrome, tracciata come CVE-2023-4863, invece di assegnarla alla libreria open-source libwebp utilizzata per codificare e decodificare le immagini in formato WebP. Ora si chiama CVE-2023-5129.
“Come in ogni progetto software”, commenta John Smith, CTO EMEA, Veracode, “gli sviluppatori non reinventano il codice se esiste già un’opzione valida, quindi non sorprende che libwebp sia ampiamente utilizzato. Si tratta dello stesso ragionamento alla base della diffusione del problema di Log4j e di altre vulnerabilità ultimamente ben note”.
Ecco come mitigare il rischio legato al bug.
Indice degli argomenti
La vulnerabilità Libwebp è zero-day
Apple Security Engineering and Architecture (SEAR) e il Citizen Lab della Munk School dell’Università di Toronto, lo scorso 6 settembre, avevano segnalato congiuntamente questo bug zero-day.
Google lo ha risolto meno di una settimana dopo. Ma ora torna alla ribalta.
“Negli ultimi anni molti software sono stati scritti utilizzando linguaggi in grado di gestire la memoria al posto dell’utente”, spiega John Smith, “cosa che rende molto più facile evitare questa tipologia di problemi. Ma quando velocità ed efficienza sono fondamentali, come nel caso dei processi di rendering di immagini in un determinato browser, è necessario utilizzare linguaggi che forniscano funzionalità di livello inferiore, aumentando la possibilità che siano presenti vulnerabilità legate alla memoria”.
I ricercatori di sicurezza di Citizen Lab hanno un’esperienza consolidata nell’individuare e rivelare zero-day sfruttate in campagne di spyware mirate, spesso legate ad attori di minacce Nation-State che prendono di mira principalmente individui ad alto rischio come giornalisti e politici dell’opposizione.
La decisione di etichettare come problema il bug di Chrome ha generato confusione nella comunità della cybersicurezza. Suscita inoltre domande la scelta di Google di classificarlo come una falla di Google Chrome invece di identificarlo come una falla in libwebp.
Il fondatore della società di consulenza sulla sicurezza Ben Hawkes (in precedenza al vertice del team Project Zero di Google) ha anche collegato CVE-2023-4863 alla vulnerabilità CVE-2023-41064.
Quest’ultima, sanata da Apple lo scorso 7 settembre, è stata protagonista di una catena di exploit di iMessage senza click (denominata BLASTPASS) per infettare gli iPhone completamente patchati con lo spyware commerciale Pegasus di NSO Group.
Massima severità
Ora è stato assegnato un altro ID CVE, CVE-2023-5129. Lo contrassegna, dunque, come un problema critico in libwebp con una valutazione massima di gravità di 10/10. Il cambiamento ha implicazioni significative per altri progetti che utilizzano la libreria open-source libwebp.
La riclassificazione di CVE-2023-5129 come vulnerabilità di libwebp riveste, infatti, una particolare importanza.
Inizialmente passata inosservata, diventa invece una potenziale minaccia alla sicurezza per numerosi progetti che condividono la libreria: 1Password, Signal, Safari, Mozilla Firefox, Microsoft Edge, Opera e i browser web nativi di Android.
Riconosciuta ufficialmente come falla di libwebp, la vulnerabilità riguarda un overflow del buffer heap in WebP, con impatto sulle versioni di Google Chrome precedenti alla 116.0.5845.187.
La vulnerabilità risiede nell’algoritmo di codifica Huffman utilizzato da libwebp per la compressione senza perdita di dati e consente agli aggressori di eseguire scritture di memoria fuori dai limiti utilizzando pagine HTML create in modo scorretto.
Questo tipo di exploit può avere gravi conseguenze, dai crash all’esecuzione di codice arbitrario e all’accesso non autorizzato a informazioni sensibili.
Come mitigare il rischio
“Per gli sviluppatori di software l’imperativo è assicurarsi che le librerie utilizzate siano sicure e aggiornate”, mette in evidenza John Smith: “Per i consumatori la sfida può essere più ardua: innanzitutto bisogna conoscere il contenuto del software che si sta acquistando. È qui che un ‘Software Bill of Materials’ come quello richiesto dal governo degli Stati Uniti può essere d’aiuto”.
Infatti, “se si sta acquistando un software, bisogna insistere nel verificare che i fornitori stiano adottando misure per garantire la sicurezza dei loro prodotti e che siano trasparenti sugli strumenti utilizzati. Questo sarebbe già un primo inizio”, conclude John Smith.
