OpenSSL HollowByte: 11 octets bastan para saturar la memoria de un servidor TLS

La falla HollowByte en OpenSSL permite enviar una solicitud TLS de 11 bytes para congelar la memoria de un servidor. Una asimetría ataque/defensa temible: poco ancho de banda, efecto máximo.

Lo que está pasando

Una vulnerabilidad llamada HollowByte afecta a OpenSSL — la biblioteca criptográfica que protege la mayoría de las conexiones HTTPS, SMTP y VPN de la web. Según las pruebas realizadas por Okta, que documentó la falla, el fallo permite a un atacante enviar una solicitud TLS de solo 11 bytes para desencadenar una saturación de memoria en el servidor, asignando hasta 131 KB por solicitud en sistemas con glibc. Esta memoria permanece bloqueada hasta que se reinicie el proceso, dejando al servidor incapaz de procesar otras conexiones.

Punto importante: OpenSSL publicó el parche HollowByte en junio, sin CVE, sin aviso público ni entrada en el registro de cambios que mencione la vulnerabilidad. Una corrección silenciosa que explica por qué algunos administradores aún desconocen su existencia.

Quién está afectado

Todos los servidores que ejecutan una versión de OpenSSL anterior al parche de junio, es decir, la inmensa mayoría de la infraestructura web no actualizada:

• Servidores web HTTPS (Apache, Nginx, etc.)
• Servicios de correo seguro (SMTPS, IMAPS)
• Servidores VPN basados en OpenSSL
• Cualquier demonio de red cuyas dependencias incluyan OpenSSL

Análisis

La asimetría de esta vulnerabilidad es su aspecto más peligroso. En un ataque DDoS clásico, el atacante debe generar un volumen significativo de tráfico para saturar el objetivo. Con HollowByte:

• 11 bytes de carga útil por solicitud
• Efecto: 131 KB de memoria asignados en el servidor, no liberados hasta el reinicio
• Resultado: un atacante con una conexión de bajo ancho de banda puede dejar fuera de servicio un servidor de alta capacidad mediante acumulación

Este tipo de asimetría es raro y constituye la firma de una vulnerabilidad de primer nivel. Se observa una mecánica similar en ataques como SlowLoris o Billion Laughs XML, pero aplicada aquí al propio handshake TLS.

Hechos vs. análisis

Hechos confirmados: fallo en OpenSSL, vector de ataque mediante una solicitud TLS de 11 bytes, asignación de 131 KB por solicitud en glibc (probado por Okta), parche lanzado en junio sin CVE ni aviso, memoria no liberada hasta reiniciar el proceso.

Análisis: el parche silencioso en sí es una señal de alarma: OpenSSL optó por corregir discretamente una vulnerabilidad grave, lo que significa que muchas instalaciones siguen expuestas sin saberlo. Actualizar a la versión parcheada de junio es urgente.

Qué hacer ahora

• Verificar la versión de OpenSSL instalada: openssl version. El parche HollowByte se lanzó en junio — asegurarse de que la versión desplegada sea posterior a esa fecha
• Actualizar OpenSSL si aún no se ha hecho: seguir security.openssl.org y las notas de versión de tu distribución
• Verificar la versión de OpenSSL integrada en tus imágenes Docker (docker run <image> openssl version) y dependencias del sistema — las imágenes no reconstruidas desde junio son vulnerables
• Activar un límite de tasa (rate-limiting) de conexiones TLS a nivel de firewall o balanceador de carga, como complemento al parche
• Monitorear el consumo de memoria de los procesos que exponen TLS (nginx, apache2, sshd…)