El ataque HollowByte de 11 bytes puede inflar la memoria de OpenSSL

Un problema recientemente revelado de denegación de servicio en OpenSSL, denominado HollowByte, permite a atacantes no autenticados forzar a los servidores a consumir grandes cantidades de memoria con una carga útil maliciosa de solo 11 bytes. El equipo de OpenSSL ya ha corregido el error sin asignarle un identificador y ha retroportado el parche a ramas anteriores.

Según un aviso del Red Team de Okta, la falla radica en cómo las versiones vulnerables manejan los mensajes del handshake TLS. Cada handshake empieza con un encabezado de 4 bytes que incluye un campo de longitud de tres bytes que describe cuántos datos deben seguir. En las versiones afectadas, OpenSSL asigna memoria según esa longitud declarada antes de que llegue la carga útil y antes de que se valide el tamaño.

El hilo de trabajo queda bloqueado, esperando indefinidamente datos que nunca llegarán.

Eso significa que un atacante puede abrir una conexión TLS, enviar una carga útil de 11 bytes que afirma que llegará un cuerpo mucho mayor y repetir el proceso en muchas conexiones. El resultado es una gran asignación de memoria con muy poco tráfico entrante.

Recomendado

El DHS pasó por alto el hackeo de HSIN dos veces antes de declarar la brecha

Okta explicó que el efecto se amplifica por la forma en que glibc gestiona la memoria. Aunque OpenSSL libera los buffers cuando las conexiones se cierran, glibc suele conservar asignaciones pequeñas y medianas para reutilizarlas en lugar de devolverlas al sistema operativo de inmediato. Al variar los tamaños declarados en oleadas de conexiones, un atacante puede fragmentar el heap y aumentar de forma sostenida el Resident Set Size (RSS) del servidor.

Al lanzar oleadas de conexiones con tamaños declarados aleatorios, un atacante impide que el asignador reutilice esos trozos liberados. El heap se fragmenta fuertemente, lo que provoca que el Resident Set Size (RSS) del servidor aumente de forma continua. Incluso después de que el atacante se desconecta, el servidor permanece permanentemente hinchado.

En las pruebas de Okta con NGINX, los sistemas de baja capacidad eran fáciles de agotar, mientras que los servidores más grandes aún podían perder hasta el 25% de la memoria sin que el ancho de banda del ataque superara umbrales comunes de alerta. Recuperar esa memoria por completo requiere reiniciar el proceso afectado.

OpenSSL está ampliamente integrado en NGINX, Apache, Node.js, Python, Ruby, PHP, MySQL y PostgreSQL, y se incluye por defecto en la mayoría de las distribuciones de Linux para el manejo de TLS y certificados. Las correcciones están disponibles en OpenSSL 4.0.1 y se han retroportado a 3.6.3, 3.5.7, 3.4.6 y 3.0.21. Esas versiones ahora amplían el búfer solo a medida que llegan los datos en lugar de confiar en la afirmación del encabezado.

Aunque el problema se trató como un "parche de endurecimiento" en lugar de una vulnerabilidad de seguridad formal, Okta instó a las organizaciones a actualizar de inmediato los paquetes de OpenSSL de su distribución.

×