ibonok/cve-2026-94300PoC autonomo e analisi per CVE-2026-94300, un use-after-free in GSS-TSIG in BIND 9.20.29, con un modello assistito da debugger della catena che va dalla fuga di memoria all'esecuzione di codice.
Nota: questa analisi e il PoC sono stati prodotti in larga misura con l'assistenza dell'IA ("AI patchwork"). Ogni affermazione su codice, diff e misurazioni dovrebbe essere verificata rispetto alle fonti citate prima di essere considerata attendibile.
Cartella PoC autonoma per la catena di sfruttamento di CVE-2026-94300 (BIND 9.20.29 con GSS-TSIG, krb5 1.20.1, jemalloc 5.3.0).
Cosa è dimostrato qui: un insieme di indirizzi divulgato (qui da gdb) è sufficiente per costruire l'esecuzione di codice nel
processo named a partire dalle primitive misurate. L'exploit consuma il leak da
docker logs; non contiene alcun indirizzo letterale.
Cosa è esplicitamente un modello (e dichiarato come tale nel report):
| Ipotesi | Motivo |
|---|---|
| Leak da gdb | La CVE non ha una primitiva di info-leak; un leak reale dovrebbe provenire da un altro bug |
ASLR disattivato (setarch -R) | senza un leak non ci sono indirizzi heap/codice |
| Controllo del contenuto degli oggetti iniettato tramite gdb | il reclaim dello slot da 8 byte liberato non è riuscito nel percorso reale con i mezzi esaminati qui (4,7M tentativi, 0 successi) — un ostacolo documentato, non una prova di impossibilità |
Nessun RCE remoto dimostrato e nessuna persistenza. Il comando viene fornito tramite --cmd sull'exploit: host/exploit.py lo consegna attraverso il canale di controllo Docker (docker exec, la stessa autorità che l'operatore già possiede) nel container; l'exploit stesso
invia solo gli indirizzi divulgati e il pacchetto catturato. Il payload scrive inoltre la riga RCE-PROOF (per verifica) e termina named.
sequenceDiagram
participant R as Researcher (host)
participant V as Container: named 9.20.29 + gdb
participant L as docker logs
R->>V: docker run -p 127.0.0.1:15353:53/udp
V->>V: TKEY capture (no send), gdb breaks on dns_db_currentversion
V->>L: LEAK: db=…, methods=…, heap=…, wire_b64=… (sha256)
V->>V: model armed, waits for host replay
R->>L: read docker logs + validate (11 checks)
R->>V: docker exec: --cmd to /tmp/rce-payload-cmd
R->>V: UDP replay of the leaked signed packet to 15353
V->>V: krb5_k_free_key → free(db) → reclaim → fake dns_db_t
V->>V: dns_db_currentversion → jmp *methods+0x30 → payload
R->>V: docker exec cat /tmp/rce-proof
| Percorso | Scopo |
|---|---|
docker/Dockerfile | Immagine vittima: BIND 9.20.29 dal tarball ISC + gdb + KDC + driver del lab |
etc/ | krb5.conf, kdc.conf, named.conf, zona (copiati in /etc dall'immagine) |
host/exploit.py | Exploit host: legge docker logs, valida, riproduce via UDP, verifica il marker |
lab/rce_victim.sh | Driver nel container: named sotto gdb, cattura senza invio, leak, attesa |
lab/rce_model.py | Modello gdb: breakpoint, blocco di leak, arming, osservazione del dispatch |
lab/rce_leak.py | Fase di leak: indirizzi + wire_b64 → stdout/file |
lab/rce_exploit.py | Fase di exploit nel container: costruisce l'oggetto falso dal leak, reclaim, dispatch |
lab/rce_shim.c | Shim a pagina fissa: tabella finta, template dns_db_t finto, payload |
lab/replay-lab.py | Cattura TKEY (--no-send) |
lab/gss_context_lab.py | Helper per il contesto GSS per la cattura |
lab/start.sh, lab/named.replay.conf | Bootstrap di KDC/keytab/zona, configurazione di named |
RACE.md | Spiegazione della race sul contesto GSS-TSIG condiviso: condivisione, accessi, trigger, misurazioni, scoping |
VERIFY.md | Verifica delle tre affermazioni rispetto al diff del sorgente 9.20.29 → 9.20.30 (locking GSS-TSIG, dump distruttivo del keyring, scoping dell'RCE) |
EXPLOIT.md | Descrizione dell'exploit con evidenze nel codice e Mermaid |
USAGE.md | Build, esecuzione, output attesi, risoluzione dei problemi |
ANAYLSE.md | Addendum di disclosure pronto per la pubblicazione (riconciliazione dell'impatto DoS vs. potenziale RCE, versioni interessate, mitigazione, rilevamento) — senza primitive di exploit |
ANALYZE.md | Versione inglese dell'addendum di disclosure |
(Questo file è README.md; gli altri documenti del PoC esistono anch'essi come RACE.md, VERIFY.md,
EXPLOIT.md, USAGE.md.)
Solo Docker + internet al momento della build. L'immagine compila BIND 9.20.29 stesso dal tarball
ufficiale ISC (https://downloads.isc.org/isc/bind9/9.20.29/bind-9.20.29.tar.xz, SHA-256 fissato),
con --with-gssapi=yes, e installa gdb, il KDC MIT Kerberos e i driver del lab. Nessun BIND della
distro, nessuna immagine base precompilata necessaria.
L'immagine contiene un'identità KDC usa e getta [email protected] (password attacker,
realm EXAMPLE.TEST, KDC su 127.0.0.1:88 solo nel container) — esclusivamente per questo lab, non
per test GSS-TSIG contro altri server; non estrarre il keytab dal container.
cd poc/CVE-2026-94300-poc
docker build -f docker/Dockerfile -t cve-2026-94300-victim .
# Terminal 1: container
docker run --rm --name cve-2026-94300-victim \
-p 127.0.0.1:15353:53/udp \
--security-opt seccomp=unconfined \
cve-2026-94300-victim # prints the LEAK block to stdout
# Terminal 2: exploit from the host, target + command as arguments
python3 host/exploit.py --ip 127.0.0.1 --port 15353 --cmd 'id > /tmp/bla'
docker exec cve-2026-94300-victim cat /tmp/bla # uid=0(root) …
Previsto (estratto):
LEAK: db=0x7ffff6901c00
LEAK: db_methods=0x7ffff7c497c0
LEAK: payload=0x7ffff7fbe37b
LEAK: wire_len=3907
HOST-EXPLOIT-VALIDATE OK checks=11
HOST-EXPLOIT-REPLAY target=127.0.0.1:15353 bytes=3907
RCE-DISPATCH-INDIRECT target=0x7ffff7fbe37b (rce_payload) match=YES
RCE-PAYLOAD-EXECUTED RCE-PROOF pid=… uid=0 euid=0 db=0x7ffff6901c00
HOST-EXPLOIT-VERDICT payload_executed=YES marker=YES
Nota di avvertenza: ISC classifica CVE-2026-94300 come remoto, Alto, CVSS 8.1 (AC:H) con potenziale esecuzione di codice. Ciò che è pubblicamente/riproducibilmente stabilito è una corruzione di memoria senza credenziali, attivata da replay (use-after-free/double-free) sul contesto GSS-TSIG condiviso — classe DoS fino a corruzione dell'heap. Un percorso verso l'esecuzione di codice è stato finora mostrato solo sotto assunzioni di modello assistite da debugger (ASLR disattivato, indirizzi/contenuti degli oggetti iniettati); non esiste alcun RCE remoto dimostrato.
Stabilito: data una leak, l'RCE consegue nel processo target. Non stabilito: un attacco remoto senza leak e senza gdb — la primitiva di info-leak e il passo di reclaim raggiunto mancano per questo. Si tratta di un insieme documentato di ostacoli, non di una prova di impossibilità; ISC include la classe di esecuzione di codice come potenziale. La base del codice (bug di sincronizzazione, dump distruttivo, cosa corregge la patch e cosa no) è verificata in VERIFY.md rispetto al diff dei due alberi; come funziona tecnicamente la race è in RACE.md. Dettagli dell'exploit e prove del codice: EXPLOIT.md, esecuzione e opzioni: USAGE.md. Divulgazione pronta per la pubblicazione: ANALYZE.md.