Alessandro Giovannini
Google ha minimizzato i potenziali rischi derivanti da una vulnerabilità che investe migliaia di applicativi.
Google ha ripresentato senza troppo clamore la divulgazione di una potenziale vulnerabilità critica legata ad un’esecuzione di codice che rischia di interessare migliaia di applicativi e framework, dopo che una precedente dichiarazione aveva lasciato intendere che il problema riguardasse solamente il browser Chrome. Vediamo di che si tratta esattamente.
Una libreria invasa dai tarli
La vulnerabilità in questione riguarda la libreria di codice libwebp, il cui scopo è appunto assicurare il rendering dei file .webp, un recente formato di file immagine introdotto per la prima volta nel 2010 e contraddistinto da una minor peso rispetto ai classici file .png (fino al 26% più leggeri), il che rende questo formato di file particolarmente adatto alla pubblicazione web, poiché contribuisce ad accelerare i tempi di caricamento delle pagine.
Ciò spiega anche perché libwebp sia ormai incluso in migliaia di applicazioni, in tutti i sistemi operativi e in altre librerie che eseguono il rendering di questo tipo di file, tra cui il framework Electron che è utilizzato per Chrome. Proprio in riferimento ad un potenziale rischio per il suo browser, qualche settimana fa Google aveva lanciato un avviso di sicurezza per quello che era stato presentato come un “heap buffer overflow in WebP in Chrome”. Nel log di sicurezza si faceva riferimento alla sola applicazione Chrome, quando in realtà il rischio potenziale riguardava qualsiasi applicativo che eseguisse al suo interno codice libwebp.
In sostanza, questa mancata comunicazione da parte di Google ha portato ad una sottovalutazione del rischio reale dato da questa vulnerabilità, che potrebbe portare malintenzionati ad inserire codice dannoso per un utente finale che, ignaro di tutto, vorrebbe solo visualizzare un’immagine .webp.
Una correzione in sordina
Resasi conto dell’errore – o costretta dalle circostante sempre più evidenti – l’azienda di Mountain View ha dovuto correggere il proprio avviso precedente con uno nuovo e molto più esaustivo, identificato con la sigla CVE-2023-5129 che ora non indica più Chrome bensì libwebp come prodotto vulnerabile. Ha inoltre innalzato il grado di pericolosità da 8.8 a 10, ovvero il livello massimo!
Anche la descrizione del problema è ora molto più dettagliata, essendo passata dalla striminzita dicitura “heap buffer overflow” ad una descrizione molto più accurata.
Con un file WebP lossless appositamente realizzato, libwebp potrebbe scrivere dati fuori dai limiti sull’heap. La funzione ReadHuffmanCodes() alloca il buffer HuffmanCode con una dimensione che proviene da un array di dimensioni precalcolate: kTableSize. Il valore color_cache_bits definisce quale dimensione utilizzare. L’array kTableSize tiene conto solo delle dimensioni per le ricerche di tabelle di primo livello a 8 bit, ma non di quelle di secondo livello. libwebp consente codici fino a 15 bit (MAX_ALLOWED_CODE_LENGTH). Quando BuildHuffmanTable() tenta di riempire le tabelle di secondo livello, potrebbe scrivere dati fuori dai limiti. La scrittura OOB nell’array sottodimensionato avviene in ReplicateValue.
Il rimedio al problema, fortunatamente, è di semplice attuazione: non serve far altro che assicurarsi di utilizzare una versione del framework Electron che sia una di queste tre: la v22.3.24, la v24.8.3 o la v25.8.1. Qui la lista delle versioni rilasciate.