NGINX corrige fallos que permiten ejecutar código en servidores sin iniciar sesión

NGINX publicó el 14 de octubre las versiones 1.30.6 (stable) y 1.31.7 (mainline) con correcciones para cinco vulnerabilidades. Tres de ellas son errores de memoria que un atacante puede provocar con peticiones HTTP manipuladas y sin iniciar sesión. En el peor caso, eso significa ejecutar código en el servidor. F5, la empresa que desarrolla NGINX, puntúa estas tres con 9,2 sobre 10 (crítica) en CVSS 4.0. Cada una solo es alcanzable con una configuración concreta, así que un servidor con NGINX no está expuesto automáticamente. F5 dice que no conoce ningún exploit público ni ataques.

Qué se ha corregido

Los tres fallos graves dependen de directivas que son habituales en configuraciones reales:

En los tres primeros casos, el desbordamiento hace caer un proceso worker de NGINX, que luego se reinicia. Con peticiones repetidas se puede conseguir que ocurra una y otra vez, así que como mínimo hay una denegación de servicio. Según F5, la ejecución de código es posible en sistemas donde la aleatorización del espacio de direcciones (ASLR) está desactivada o donde el atacante puede esquivarla. El fallo de alias está en el código desde la versión 0.1.29, publicada en 2005.

El fallo de los tickets de sesión es de otra clase. Una de las claves rotadas se quedó sin inicializar, y F5 explica que un atacante podría falsificar una sesión TLS y usarla para saltarse la comprobación de certificados de cliente. Eso importa en servidores que admiten usuarios por certificado, como paneles de administración y servicios internos.

¿Crítica o media?

Las dos valoraciones parecen contradictorias. En la página de avisos de nginx.org, los cinco fallos figuran como "medium". En los registros CVE de F5, los tres errores de memoria reciben 9,2 en CVSS 4.0 y 8,1 (alta) en CVSS 3.1. La diferencia viene de las condiciones. El vector CVSS indica que el ataque no necesita cuenta pero tiene una complejidad alta, porque solo funciona con una configuración que coincida. Security Affairs escribió el 16 de octubre sobre once problemas corregidos. La cifra mayor abarca más que NGINX: ese mismo día F5 lanzó actualizaciones para productos relacionados, entre ellos el módulo de scripting njs, Ingress Controller y Gateway Fabric.

Cómo comprobar tu propio servidor

NGINX funciona delante de muchos servicios autoalojados en servidores alquilados, como paneles de VPN y proxy, recursos compartidos de archivos y sitios pequeños. Si administras uno, bastan dos comandos para empezar. nginx -v muestra la versión, y nginx -T | grep -nE 'alias|request_filename|aio|ssi |ssl_session_cache|ssl_session_ticket|map ' lista las directivas de la tabla en toda la configuración cargada.

El número de versión por sí solo puede engañar. Debian y Ubuntu mantienen versiones antiguas de NGINX y les añaden parches de seguridad, de modo que "1.22" o "1.26" en un servidor no dice si las correcciones de octubre están incluidas. El 17 de octubre, el rastreador de seguridad de Debian seguía listando los paquetes de bookworm y trixie como vulnerables. Consulta el rastreador de tu distribución y actualiza con apt update && apt upgrade cuando aparezca un paquete corregido. Si usas los paquetes oficiales de nginx.org, las versiones corregidas son la 1.30.6 y la 1.31.7.

Hasta que llegue la corrección, F5 aconseja cambiar la configuración: evitar alias y $request_filename en los bloques afectados, usar capturas con nombre en map en lugar de $1 y $2, desactivar aio o dejar de servir páginas SSI, y cargar las claves de tickets desde un archivo con ssl_session_ticket_key o apagar los tickets con ssl_session_tickets off. Nuestra guía para proteger un VPS cubre el resto de la higiene básica de un servidor.