HollowByte: 11 bytes bastan para dejar tu servidor sin memoria (y OpenSSL lo arregló sin avisar)

Once bytes

Hay ataques que impresionan por su sofisticación y ataques que impresionan por su economía. HollowByte es de los segundos: un payload de 11 bytes —menos que la palabra "ateneasystems"— puede obligar a un servidor con OpenSSL sin parchear a reservar hasta 131 KB de memoria por conexión, antes de que haya autenticación de ningún tipo. Repite la jugada unas cuantas miles de veces y la memoria del servidor se hincha hasta que el sistema empieza a matar procesos.

Lo destapó el equipo de seguridad de Okta a mediados de julio, y el día 18 llegó a la lista oss-security, que es cuando el mundillo sysadmin se enteró en masa. Pero la parte más incómoda de la historia no es el fallo: es cómo se arregló.

En una frase

OpenSSL reservaba el búfer de recepción TLS fiándose del tamaño que declara el cliente, antes de que llegara un solo byte real. Un atacante remoto y sin autenticar puede explotar eso para inflar y fragmentar la memoria del servidor de forma permanente —el proceso no la suelta ni cuando el atacante se desconecta— hasta forzar una denegación de servicio. No hay robo de datos ni ejecución de código: "solo" te dejan el servidor inservible.

Cómo funciona, en dos pasos

Paso 1 — la reserva a ciegas. Durante el handshake TLS, el cliente anuncia cuánto va a ocupar lo que envía. Las versiones antiguas de OpenSSL reservaban el búfer completo basándose en esa cifra declarada. Once bytes bien construidos bastan para reclamar la reserva máxima. El atacante no necesita enviar los datos prometidos: la memoria ya está apartada.

Paso 2 — la fragmentación que no se va. Aquí está la maldad fina. Cuando la conexión se cierra, OpenSSL libera el búfer… pero glibc no devuelve esa memoria al sistema operativo: la retiene por si el proceso la reutiliza. Lanzando oleadas de conexiones con tamaños declarados aleatorios, el atacante consigue que esos huecos liberados nunca encajen con las siguientes reservas. Resultado: la memoria residente (RSS) del proceso sube y no baja jamás, ni siquiera con el ataque terminado. La única forma de recuperarla es reiniciar el servicio.

Las pruebas del equipo de Okta sobre un Nginx con OpenSSL sin parchear lo dejan claro: en una máquina de 1 GB de RAM, el servidor acabó matado por el OOM killer con 547 MB de memoria congelada e inutilizable. Una máquina perfectamente sana, asesinada por fragmentación.

La parte polémica: el parche silencioso

El fix existe y es elegante: OpenSSL ya no se fía de la cifra declarada, sino que agranda el búfer conforme llegan los bytes reales. Un cliente que promete mucho y no envía nada, ahora no cuesta nada.

El problema es cómo se distribuyó: sin CVE y sin aviso de seguridad. OpenSSL lo catalogó como mejora de robustez ("hardening") y lo incorporó calladamente en la versión 4.0.1, con backports a 3.6.3, 3.5.7, 3.4.6 y 3.0.21.

¿Por qué eso es un problema? Porque medio mundo prioriza parches por CVE. Los escáneres de vulnerabilidades buscan CVEs. Los equipos de seguridad puntúan por CVSS. Si no hay CVE, para muchas organizaciones el parche simplemente no existe — y mientras tanto, el mecanismo del ataque ya está explicado con pelos y señales en internet. Es la combinación menos deseable: exploit documentado públicamente, urgencia invisible en los sistemas de gestión.

A quién afecta

A casi todo el mundo, porque OpenSSL está debajo de casi todo:

• Servidores web: Apache, Nginx (cuando enlazan OpenSSL para TLS).
• Runtimes: Node.js, Python, Ruby, PHP.
• Bases de datos: MySQL, PostgreSQL, si tienen TLS activado en conexiones expuestas.

La condición es sencilla: un servicio que acepte conexiones TLS desde internet con una versión de OpenSSL anterior a las parcheadas. El candidato obvio es el servidor web, pero un MySQL con TLS expuesto también entra en el saco.

Qué tienes que hacer hoy

1. Mira qué versión de OpenSSL tienes

openssl version

Objetivo según tu rama: 3.0.21, 3.4.6, 3.5.7, 3.6.3 o 4.0.1 (o superiores).

Ojo con el matiz de siempre en las distros, agravado aquí por la ausencia de CVE: Debian, Ubuntu o Alma pueden backportear el fix manteniendo el número de versión, o tardar más en incorporarlo precisamente porque no hay CVE que les marque la urgencia. Comprueba el changelog del paquete (apt changelog openssl o el tracker de seguridad de tu distro) en lugar de fiarte solo del número.

2. Actualiza la librería

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade openssl libssl3*

# RHEL / AlmaLinux / Rocky
sudo dnf update openssl openssl-libs

3. Reinicia los servicios que la usan (imprescindible)

Y aquí el error clásico: OpenSSL es una librería compartida. Actualizar el paquete no sirve de nada mientras los procesos sigan cargando en memoria la versión vieja. Un reload tampoco basta: hace falta reiniciar los servicios.

# Ver qué servicios siguen usando la librería vieja
sudo needrestart

# O a mano: reiniciar lo expuesto a internet
sudo systemctl restart nginx    # o apache2, mysql, etc.

Si no tienes needrestart, lsof | grep libssl | grep DEL te enseña los procesos que aún cargan la versión borrada.

Lo que hacemos nosotros

Este fallo es un ejemplo de libro de por qué no basta con mirar la lista de CVEs: si tu proceso de parcheo depende solo de eso, HollowByte se te cuela por debajo del radar. En los servidores que gestionamos, la pasada de actualizaciones incluye las listas de seguridad (oss-security, los avisos de cada distro) además de los CVEs, y tras actualizar OpenSSL se reinician los servicios expuestos — no solo se recargan.

También es un buen recordatorio de dimensionamiento: el ataque mató una máquina de 1 GB con 547 MB congelados. Monitorizar la memoria residente de los procesos expuestos (y alertar cuando crece sin volver a bajar) convierte este tipo de ataque en una gráfica rara un martes por la tarde, en vez de en una web caída un domingo por la noche.

Si no sabes qué versión de OpenSSL corre debajo de tu web —o quién tendría que darse cuenta si tu servidor empezara a hincharse—, hablamos.

Referencias

• OpenSSL "HollowByte" DoS via attacker-controlled memory allocation — oss-security
• OpenSSL HollowByte: A DoS Hiding in 11 Bytes — Okta Security
• HollowByte DDoS flaw bloats OpenSSL server memory with 11-byte payload — BleepingComputer
• OpenSSL Silently Fixes 'HollowByte' DoS Vulnerability — SecurityWeek
• HollowByte: Denial-of-service vulnerability in OpenSSL — heise online