7-Zip: 8 bug memory access, il pericolo nasconde nelle build 32-bit
GitHub Security Lab svela otto vulnerabilità di memory access in 7-Zip 26.00. Un bug di 15 anni nel parser SquashFS diventa esploitable solo sulle build 32-bit
Contenuto
Il GitHub Security Lab ha pubblicato il 22 maggio 2026 un advisory su otto vulnerabilità di memory access nel parser di 7-Zip 26.00, tutte corrette il 27 aprile 2026 nella release 26.01. La rivelazione tecnica più inquietante non riguarda la complessità dell'exploit, ma la sua premessa: un bug latente dal 2010, rimasto innocuo per quindici anni, si è trasformato in un vettore di information disclosure esattamente perché 7-Zip continua a distribuire build ufficiali a 32 bit per Windows.
Gli identificatori GHSL-2026-115 fino a GHSL-2026-122 coprono formati diversi — SquashFS, UEFI, UDF, WIM, Ar, 7z — con pattern ricorrenti: integer overflow in build 32-bit, mancata validazione di valori letti da disco, buffer allocati senza inizializzazione e return value di funzioni I/O ignorati. Il risultato è un attacco silenzioso: l'utente apre un archivio apparentemente normale e ne estrae, senza alcun crash visibile, byte di memoria heap appartenenti al processo 7-Zip.
- Otto vulnerabilità GHSL-2026-115/122 nel parser di 7-Zip 26.00, patchate in 7-Zip 26.01 rilasciato il 27 aprile 2026
- Il bug SquashFS GHSL-2026-116 esiste dal 7-Zip 9.18 ed è latente su build 64-bit, attivo solo su 32-bit con CVSS 6.5
- Le build 32-bit di 7-Zip rimangono distribuite ufficialmente
- Il parser UEFI capsule permette disclosure di memoria heap non inizializzata fino a 1 GiB tramite file .scap troncato
Un overflow di 15 anni che il 32-bit risveglia
Il caso più emblematico è GHSL-2026-116, localizzato nel parser SquashFS. Il codice vulnerabile risiede in SquashfsHandler.cpp, righe 2153-2198, dove la variabile offsetInBlock è dichiarata come UInt32 senza successiva promozione a 64 bit nel calcolo offsetInBlock + blockSize. Su build 64-bit l'operazione avviene nativamente in 64 bit e il wrap non si manifesta; su build 32-bit l'integer overflow bypassa il controllo dei limiti del frammento, consentendo a memcpy di leggere memoria heap precedente al buffer di cache.
L'advisory del GitHub Security Lab lo descrive con precisione:
"32-bit integer overflow in the SquashFS ReadBlock function allows an attacker-controlled node.Offset value to bypass the fragment bounds check, causing memcpy to read heap memory preceding the cache buffer into the extracted file"
La memoria heap precedente al buffer potrebbe contenere, in scenari non documentati nell'advisory, residui di sessioni precedenti o dati di altri file processati. La dimensione massima di disclosure per singolo blocco SquashFS raggiunge circa 8 MiB, sebbene il proof of concept pubblicato dimostri una lettura effettiva di circa 32 KiB. Il bug è presente dal 7-Zip 9.18, rilasciato nel 2010: quindici anni di invisibilità terminati non per correzione preventiva, ma per la scelta architetturale di mantenere vivo il supporto 32-bit.
UEFI: il return value ignorato e il gigabyte di memoria spettatore
Un pattern differente, ma altrettanto pericoloso, governa GHSL-2026-117 nel parser UEFI capsule. In UefiHandler.cpp, righe 1592-1595, il codice chiama ReadStream_FALSE(stream, buf0 + kHeaderSize, _h.CapsuleImageSize - kHeaderSize) senza controllare il valore di ritorno. L'omissione del macro RINOK — la convenzione interna di 7-Zip per la gestione degli errori — permette che un file .scap troncato o malformato proceda nell'elaborazione con buffer parzialmente vuoto.
Il buffer stesso è allocato con new Byte[size] senza zero-inizializzazione, quindi contiene residui della memoria heap del processo. La dimensione massima teorica raggiunge circa 1 GiB, vincolata dal campo CapsuleImageSize dell'header UEFI. I byte non inizializzati vengono esposti attraverso GetStream e finiscono nell'output estratto. L'advisory evidenzia il punto esatto con una notazione che racchiude l'errore in un commento: // ← NO RINOK! — un dettaglio stilistico che denuncia la fragilità del pattern di lettura.
La proof of concept e l'evidence convergente
Il GitHub Security Lab ha fornito una proof of concept completa per GHSL-2026-116: un'immagine SquashFS v4 con Offset=0xFFFFFFFC che, aperta in una build 32-bit con AddressSanitizer attivo, genera un output diagnostico inequivocabile. L'esecuzione produce heap-buffer-overflow on address 0x052028fc, con stack trace che identifica precisamente la riga 2198 di SquashfsHandler.cpp come punto di lettura oltre il limite.
L'evidence map dell'advisory si fonda su tre pilastri convergenti: il codice sorgente vulnerabile con le linee esatte, l'output ASan con indirizzo e offset, il PoC funzionante che chiude il ciclo dimostrativo. Questa struttura è tipica degli advisory GHSL e distingue la ricerca da segnalazioni più superficiali. La disclosure è avvenuta il 21 aprile 2026 tramite il sistema private issues di SourceForge; il fix è stato rilasciato il 27 aprile; la pubblicazione pubblica ha atteso circa 25 giorni, un intervallo di embargo coerente con le pratiche standard ma che lascia un margine di esposizione per gli utenti non aggiornati.
Analisi: il vero costo del supporto legacy
La sezione seguente contiene analisi editoriale basata sui fatti documentati nell'advisory.
Le build 32-bit di 7-Zip sono distribuite ufficialmente su 7-zip.org. Questa scelta architetturale, puramente documentata come fatto, ha conseguenze di sicurezza misurabili: GHSL-2026-116 è latente su 64-bit e diventa esploitable solo su 32-bit. L'advisory non documenta le motivazioni di Igor Pavlov per mantenere tale supporto; la compatibilità legacy è un'ipotesi plausibile ma non verificata.
Il costo concreto è un moltiplicatore di attack surface. Dove un utente 64-bit è protetto dal semplice ampliamento dei registri, l'utente 32-bit espone memoria heap processo a file archivio controllati dall'attaccante. La differenza non è nel parser — identico in entrambe le build — ma nell'ambiente di esecuzione che il vendor sceglie ancora di fornire.
Cosa fare adesso
- Aggiornare immediatamente a 7-Zip 26.01 o superiore: il 27 aprile 2026 il vendor ha rilasciato la versione corretta, quindi ogni installazione precedente è potenzialmente vulnerabile
- Disinstallare o isolare le build 32-bit anche su sistemi a 64 bit: l'architettura x86-32 è il moltiplicatore di attack surface che rende GHSL-2026-116 esploitable, non un requisito funzionale per l'uso desktop moderno
- Verificare le pipeline CI/CD e i sistemi forensi che processano archivi automaticamente: questi ambienti sono i più esposti perché l'attacco non richiede interazione umana e non genera crash visibili
- Applicare il principio generale di sicurezza — non citato nell'advisory ma coerente con il caso — di trattare con cautela gli archivi in ingresso anche da fonti apparentemente fidate
Domande frequenti
Le vulnerabilità permettono esecuzione di codice remoto?
No. L'advisory classifica GHSL-2026-116 come information disclosure con CVSS 6.5 (Medium), vettore AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. Non è documentata code execution.
Perché il bug è rimasto nascosto per 15 anni?
Perché su build 64-bit l'operazione offsetInBlock + blockSize avviene in 64 bit e il wrap non si verifica. Il bug è tecnicamente presente nel sorgente ma non triggerabile. Solo l'esistenza continuata di build 32-bit lo ha reso esploitable.
Quanto memoria può trapelare in un singolo attacco?
Fino a 8 MiB per blocco SquashFS (dimensione massima teorica), circa 32 KiB nel PoC dimostrato, fino a 1 GiB per il parser UEFI capsule con file .scap troncato.
È necessario aggiornare anche su sistemi 64-bit?
Sì. Sebbene GHSL-2026-116 sia latente su 64-bit, le altre vulnerabilità della serie GHSL-2026-115/122 interessano formati diversi e pattern diversi; il fix completo è in 7-Zip 26.01.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.