captain-woof/cve-2026-25243POC stabile per CVE-2026-25243 (doppio-free in Redis RESTORE -> esecuzione remota di codice)
Verificato su Rocky Linux 8.10, aarch64, Redis 8.6.2, jemalloc 5.3.0.
Riferimento: https://www.zeroday.cloud/blog/redis-cve-2026-25243-deep-dive
TLDR; Exploit stabile, funziona su diverse distribuzioni e architetture.
Cos'è? Una vulnerabilità di corruzione della memoria in Redis che consente a un attaccante autenticato di eseguire comandi arbitrari come utente Redis. L'attacco è reale e richiede un solo comando RESTORE — una normale operazione Redis, non riservata agli amministratori. Questo exploit dimostra una RCE completa in meno di un secondo.
Impatto? Qualsiasi client Redis autenticato può innescarla, e il danno è totale: esecuzione arbitraria di codice nel processo Redis (spesso in esecuzione come root nei container). Non c'è modo di mitigare senza applicare la patch a Redis stesso.
Come funziona in sintesi? Redis ha una funzionalità di serializzazione (RESTORE) che prende un blob di dati binari e lo ricostruisce come oggetto Redis. Il codice che valida il formato del blob e quello che lo deserializza non concordano su come interpretare certe sequenze — un bug che l'attaccante sfrutta per corrompere l'heap. Una volta corrotto l'heap, l'attaccante ottiene la capacità di leggere e scrivere qualsiasi indirizzo di memoria nel processo Redis e, da lì, di dirottare lo stato interno del server per eseguire un comando di shell.
La vera tecnica dell'exploit: Non si tratta di un semplice crash. È una catena di sfruttamento dell'heap: corruzione → sovrapposizione → R/W arbitrario → leak di informazioni → individuazione della struct del server → dirottamento dei puntatori a funzione → RCE. L'exploit esegue 9 fasi e richiede il leak di più indirizzi a runtime, l'analisi di strutture binarie e il rilevamento dell'aliasing di memoria. Ciò che lo rende funzionante su più architetture (x86-64, aarch64, ecc.) è che tutti gli indirizzi vengono ottenuti tramite leak dal target stesso, non ipotizzati.
CVE-2026-25243 è una coppia di bug double-free raggiungibili da un singolo comando RESTORE autenticato. RESTORE key ttl <serialized-value> deserializza un blob RDB controllato dall'attaccante; entrambi i bug vivono nello spazio tra il validatore che controlla il blob e il convertitore che lo materializza.
Bug 1 — conversione legacy zipmap (CWE-415, il percorso usato da questo exploit). Il validatore zipmap (zipmapValidateIntegrity()) e il convertitore (zipmapNext()) non concordano su una codifica ridondante della lunghezza. La lunghezza piccola 4 può essere legittimamente scritta nella forma lunga di cinque byte FE 04 00 00 00. Il validatore consuma un certo numero di byte, il convertitore un altro — una desincronizzazione di parsing di 4 byte. Il convertitore percorre quindi una struttura diversa da quella validata, lpSafeToAdd() fallisce dopo che il campo è già stato inserito nel dizionario, e il percorso di cleanup libera il campo due volte: una volta tramite dictRelease() e un'altra tramite sdsfree().
Bug 2 — caricamento del PEL dei consumatori di stream (CWE-415). In rdbLoadStreamConsumersGroup(), un PEL di un consumatore contenente un ID duplicato fa fallire la seconda raxTryInsert(), che chiama streamFreeNACK() su uno streamNACK ancora di proprietà del PEL globale del gruppo. Liberato due volte. (Selezionabile con --vuln-type stream.)
Entrambi i bug consegnano all'attaccante un blocco di memoria simultaneamente libero e referenziato — il classico punto di partenza per un exploit di sovrapposizione dell'heap.
Impatto: un client Redis autenticato (senza diritti di amministrazione; RESTORE è un normale comando dati) ottiene l'esecuzione arbitraria di codice come utente redis — root nell'immagine container predefinita.
Nove fasi, ognuna delle quali trasforma una primitiva più debole in una più forte:
| Fase | Primitiva ottenuta | Meccanismo |
|---|---|---|
| 0 | profilo del target | INFO server / INFO memory → versione, architettura, distro, pid, percorso dell'eseguibile, tempo di avvio, allocatore |
| 1 | double free | RESTORE con zipmap (o stream) malformato |
| 2 | due chiavi che condividono la memoria | spruzza chiavi marker sul chunk liberato, rileva l'aliasing, poi sovrascrive l'header SDS di una chiave attraverso la sua gemella per espanderla a una "memview" da 1 MB |
| 3 | R/W arbitrario | trova un oggetto INCRBYFLOAT dentro la memview, dirotta il suo campo ptr: GETRANGE/SETRANGE su quella chiave ora legge/scrive qualsiasi indirizzo |
| 4 | puntatore all'immagine | scansiona l'heap all'indietro per trovare un valore dentro l'immagine di redis-server |
| 5 | &server | scendi fino all'header ELF, analizza i program header, dumpa il segmento scrivibile, confronta server.pid |
| 6 | payload in memoria | scrivi "/bin/sh", "-c", "<cmd>" più un array argv nella memview |
| 7 | struct dirottata | sovrascrivi server.executable, server.exec_argv e server.enable_debug_cmd |
| 8 | RCE | DEBUG CRASH-AND-RECOVER → restartServer() → execve(server.executable, server.exec_argv, environ) |
python3 exploit.py --host 127.0.0.1 --port 6379 \
--password mypassword --cmd 'id > /tmp/pwned123.txt'
Verifica:
cat /tmp/pwned123.txt
# uid=0(root) gid=0(root) groups=0(root)
Punto di partenza: l'exploit era solo x86-64 e moriva in fase 3 sul target aarch64. Stato finale: RCE completa su aarch64 Rocky Linux 8.10 in meno di un secondo, 116 comandi Redis.
a) Rilevamento delle caratteristiche del target a runtime (nuovo, fase 0). Non si assume più nulla sul target. INFO server + INFO memory forniscono la versione di Redis, l'architettura della CPU (dalla riga os:), la famiglia di distribuzione (dedotta da gcc_version), l'allocatore e — cosa più importante — tre punti di ancoraggio di validazione: process_id, executable e l'esatto stat_starttime (server_time_usec/1e6 - uptime_in_seconds). Le fasi successive confrontano questi valori invece di fare ipotesi.
b) Layout di memoria indipendente dall'architettura. Le quattro costanti x86-64 hardcoded (BINARY_ADDR_MIN/MAX, HEAP_ADDR_MIN/MAX) sono sostituite da una tabella per architettura (ARCH_PROFILES) che copre x86_64, aarch64 (VA sia a 39 che a 48 bit), riscv64, ppc64le e s390x, con entrambi i posizionamenti ET_EXEC ed ET_DYN per ciascuna, più un'ampia fallback generica per qualsiasi cosa non elencata. Questa era la vera ragione per cui l'exploit falliva su questo target: il puntatore leakato 0x0000ffff8a5fdf32 è un perfetto indirizzo mmap aarch64 che il controllo di intervallo x86-64 respingeva.
c) Validazione del leak basata sul consenso (fase 3). Invece di fidarsi di una finestra heap hardcoded, la scansione ora raccoglie tutti gli oggetti 1337.NNNNNN strutturalmente validi nella memview e richiede che almeno due di essi derivino lo stesso indirizzo base della memview (ptr - offset_of_value). In pratica 502 candidati concordano, una prova che nessuna tabella di intervalli può offrire. Il puntatore confermato calibra poi la finestra heap a runtime. La validazione del formato è stata inoltre spostata prima del test di controllo scrittura (costoso in termini di round-trip).
d) Limite di scansione della fase 3 (correzione di bug). La scansione arrivava a un limite hardcoded di 10 MB mentre la memview è di 1 MB, quindi leggeva oltre la fine, otteneva una risposta vuota e abortiva con AssertionError: Empty data from memview. Ora è limitata dalla STRLEN reale della memview, legge 256 KB per round-trip invece di 64 KB, e il loop inutile di retry-sleep 6×1s è stato rimosso.