Laboratorio privado de Nginx Rift ASLR, cadena de exploits y grabaciones de demostración
Prueba de concepto de RCE para CVE-2026-42945, un desbordamiento crítico de búfer en el montón en ngx_http_rewrite_module de NGINX introducido en 2008. El error permite ejecución remota de código no autenticada contra servidores que utilizan directivas rewrite y set.
Esta bifurcación extiende el PoC original con una cadena de bypass de ASLR que combina el desbordamiento de NGINX con una primitiva común de LFI/lectura arbitraria de archivos en el mismo host. La primitiva de lectura de archivos se utiliza para recuperar los mapas del worker de nginx, libc y /proc/<worker>/mem en vivo, y luego derivar la dirección de system() y los objetivos de montón utilizables de forma remota.
Versiones anteriores de este laboratorio forzaban intencionalmente un fallo de un worker de nginx para que el servicio escribiera un volcado de núcleo, luego obtenían y analizaban ese volcado de núcleo a través de la primitiva de lectura de archivos para recuperar el estado del proceso sensible a ASLR, incluidos los objetivos del montón. En este repositorio, coreless es solo una abreviatura de "sin un volcado de núcleo legible": la ruta predeterminada actual reemplaza esa dependencia del volcado de núcleo con lecturas de memoria procfs en vivo, mientras que la ruta heredada conservada core-guided todavía utiliza el volcado de núcleo generado del worker.
Esta vulnerabilidad — junto con otros tres problemas de corrupción de memoria (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) — fue descubierta de forma autónoma por el sistema de análisis de seguridad de depthfirst después de un solo clic al incorporar el código fuente de NGINX.
¿Quieres encontrar problemas como este en tu propio código? Prueba el mismo sistema en https://depthfirst.com/open-defense.
El motor de scripts de NGINX utiliza un proceso de dos pasos: primero calcular el tamaño de búfer requerido, luego copiar los datos. El flag is_args se establece en el motor principal cuando un reemplazo de rewrite contiene ?, pero el paso de cálculo de longitud se ejecuta en un submotor recién inicializado a cero. Por lo tanto:
is_args = 0 → devuelve la longitud de captura sin procesar.is_args = 1 → llama a ngx_escape_uri con NGX_ESCAPE_ARGS, expandiendo cada byte escapable a 3 bytes.La copia desborda el búfer de montón de tamaño insuficiente con datos URI controlados por el atacante. La explotación utiliza feng shui de montón entre solicitudes para corromper el puntero cleanup de un ngx_pool_t adyacente (rociado a través de cuerpos POST, ya que los bytes URI no pueden contener bytes nulos), redirigiéndolo a un ngx_pool_cleanup_s falso que invoca system() al destruir el pool.
Lee más sobre este bug en nuestro informe técnico.
| Producto | Afectado | Corregido en |
|---|---|---|
| NGINX Open Source | 0.6.27 – 1.30.0 | 1.31.0, 1.30.1 |
| NGINX Plus | R32 – R36 | R36 P4, R35 P2, R32 P6 |
Aviso completo del proveedor: https://my.f5.com/manage/s/article/K000160932
Esta bifurcación mantiene intacto el PoC de divulgación original, pero agrega una segunda pista de investigación centrada en una pregunta más realista:
¿Se puede explotar el bug contra una máquina virtual x86_64 Linux real con ASLR habilitado, sin depender de desplazamientos fijos de Docker/laboratorio?
La respuesta en esta bifurcación de investigación es sí, con restricciones importantes. Las cadenas funcionales no deshabilitan ASLR y no utilizan las direcciones fijas originales de montón/libc. En su lugar, derivan el estado de ejecución a través de primitivas accesibles por HTTP en el mismo puerto, y luego seleccionan el objetivo de montón final a partir de datos de divulgación obtenidos de forma remota.
Ahora hay dos pistas de exploit con ASLR habilitado, con la ruta coreless tratada como el mejor PoC actual:
nginx_rifter.py: el punto de entrada de evaluación y exploit integrado, limpio y autocontenido. Su método de exploit predeterminado ahora es la cadena coreless /proc/<nginx-worker>/mem.nginx_rifter_core_v2_1.py: la versión conservada heredada de nginx_rifter.py guiada por núcleo. Es útil para reproducir la ruta de investigación anterior de volcado de núcleo probada en VM, pero ya no es el PoC preferido.tools/proc_mem_coreless_exploit.py: el arnés de investigación coreless independiente anterior. Su lógica se ha fusionado en nginx_rifter.py; la herramienta permanece para la reproducción de experimentos sin procesar.La topología objetivo es intencionalmente del mismo puerto:
/api/.../lfi.php?file=.../phpinfo.phpLa ruta actual coreless proc-mem realiza los siguientes pasos de alto nivel:
/proc/<pid>/maps del worker de nginx y el archivo libc mapeado.system() para ese worker./proc/<worker>/mem a través de la primitiva de lectura de archivos.La ruta heredada guiada por núcleo realiza una derivación de dirección base similar, luego fuerza intencionalmente un fallo de un worker, lee el archivo de núcleo generado a través de LFI y extrae ese núcleo en busca de slots de limpieza falsos rociados. Eso fue un puente de investigación útil, pero depende de la política de volcado de núcleo y los permisos del sistema de archivos que son menos comunes en implementaciones predeterminadas.
Esto no es lo mismo que la demostración original determinista de Docker. La ruta de VM x86_64 deja habilitado el ASLR normal de Linux y recalcula las direcciones específicas del proceso en cada ejecución. La ruta Docker coreless también deja ASLR habilitado y elimina el requisito inusual de núcleo legible, pero depende del comportamiento de permisos de procfs que debe verificarse para la clase objetivo.
Esta bifurcación es un laboratorio de investigación controlado. Las cadenas con ASLR habilitado dependen de condiciones sólidas que no son suposiciones universales de producción: