Okta descubrió una vulnerabilidad de denegación de servicio llamada HollowByte en OpenSSL que permite agotar la memoria del servidor mediante fragmentación en sistemas glibc. Aunque OpenSSL lanzó parches en junio para varias versiones, lo hizo sin asignar un CVE ni publicar avisos oficiales, clasificándolo solo como una mejora de robustez. Se recomienda actualizar a las versiones corregidas, ya que las defensas estándar de límite de conexiones no evitan este ataque.



Once bytes harán que un servidor OpenSSL sin parchear reserve hasta 131 KB de
memoria para un mensaje que nunca llega. En los sistemas glibc que Okta probó, esa
memoria desaparece hasta que el proceso se reinicia. OpenSSL lanzó la corrección HollowByte en junio sin CVE, sin aviso y sin ninguna
entrada en el registro de cambios que lo señalara. El Red Team de Okta, que informó del
error de denegación de servicio y le puso nombre, publicó los detalles el jueves. Las versiones corregidas son OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 y 3.0.21
[https://github.com/openssl/openssl/releases], todas fechadas el 9 de junio. Cada versión en esas ramas anterior a las corregidas lo tiene. Nada en un flujo normal de parches te llevará hacia ellas: no hay un identificador para que un escáner lo coincida ni un aviso para leer. El fallo es que OpenSSL confió en la palabra del atacante. Cada mensaje de saludo TLS lleva un encabezado de 4 bytes, de los cuales tres bytes declaran qué tan largo será el cuerpo. Las versiones anteriores hacían crecer el búfer de recepción a ese tamaño declarado en el momento en que llegaba el encabezado, antes de que apareciera un solo byte del cuerpo y antes de que se ejecutaran las propias comprobaciones del saludo. Para un ClientHello entrante, el límite es de 131 KB. Entonces el hilo de trabajo se bloquea, esperando un cuerpo que nunca llega. Sin autenticación, sin sesión, sin intercambio de claves.

La memoria no regresa

Por sí solo, se trata de un ataque de agotamiento de conexiones, y esos son tan viejos como
Slowloris. Lo que hace que HollowByte sea persistente es glibc. Cuando el atacante cierra la conexión, OpenSSL libera el búfer, pero glibc retiene fragmentos pequeños y medianos para reutilizarlos en lugar de devolverlos al núcleo. El ataque varía el tamaño declarado en cada conexión y, en las pruebas de Okta, eso fue suficiente para evitar que el asignador reutilizara lo que había liberado. El montículo se fragmenta, el tamaño del conjunto residente aumenta y permanece así mucho después de que el atacante se haya ido. En las pruebas de NGINX de Okta, un servidor de 1 GB fue eliminado por falta de memoria (OOM-killed) con 547 MB de memoria congelada en fragmentos. En un servidor de 16 GB, HollowByte bloqueó el 25% de la memoria del sistema sin llegar nunca a superar el límite de conexiones, razón por la cual el Red Team dice que "las defensas estándar de limitación de conexiones no lo detendrán"
[https://sec.okta.com/articles/2026/06/openssl-hollowbtye-a-dos-hiding-in-11-bytes/]. Esas cifras son propias de Okta y no publicó ningún código de explotación junto a ellas. No se encontró ningún repositorio público de prueba de concepto en GitHub hasta el 18 de julio.

OpenSSL decidió que esto no era una vulnerabilidad

La solicitud de extracción [https://github.com/openssl/openssl/pull/30792] de Matt Caswell, quien escribió el parche, lo deja claro: el equipo de seguridad decidió "manejar esto solo como una corrección de 'error o endurecimiento'". La propia política de seguridad de OpenSSL [https://openssl-library.org/policies/general/security-policy/] define cuatro niveles de severidad, desde Crítica hasta Baja, y el "error o endurecimiento" no está entre ellos. Incluso un problema Bajo obtiene un CVE, una nota en el registro de cambios y una entrada en la página de vulnerabilidades. HollowByte no tiene ninguna de las tres. No se encontró ninguna mención de la corrección en las notas de lanzamiento [https://github.com/openssl/openssl/releases/tag/openssl-4.0.1] ni en las 23 entradas del registro de cambios de OpenSSL 4.0.1 [https://github.com/openssl/openssl/blob/openssl-4.0.1/CHANGES.md]. OpenSSL no ha dicho por qué. Aquí está el argumento para ellos: 131 KB por conexión es poco, cada servidor TLS asigna memoria por conexión y una asignación limitada no es una vulnerabilidad. La respuesta de Okta es que la memoria nunca regresa. Se ha preguntado a OpenSSL por qué HollowByte fue clasificado por debajo de Bajo y si la corrección llegó a las ramas de soporte extendido 1.1.1 y 1.0.2. También se ha preguntado a Okta si la fragmentación sobrevive a asignadores distintos de glibc. Esta historia se actualizará con cualquier respuesta. La línea del proyecto es más fina de lo que parece. En enero, OpenSSL asignó el CVE-2025-66199 [https://openssl-library.org/news/vulnerabilities-3.6/#CVE-2025-66199], calificado como Bajo, a un error de compresión de certificados TLS 1.3 en el que una longitud proporcionada por un par hacía crecer un búfer de montículo antes de la validación, con un valor de unos 22 MiB por conexión. Ese requería que cuatro cosas coincidieran: compresión de certificados compilada, un algoritmo de compresión disponible, la extensión negociada y, en servidores, que se solicitaran certificados de cliente. HollowByte no necesita ninguna de ellas. La misma versión del 9 de junio asignó el CVE-2026-34183 [https://openssl-library.org/news/vulnerabilities-3.6/#CVE-2026-34183], calificado como Moderado, al crecimiento de memoria ilimitado en el manejador QUIC PATH_CHALLENGE. Ambos son DoS de agotamiento de memoria. Ambos recibieron números. La versión también cerró 18 CVE, incluido un error de severidad Alta de uso-después-de-liberación en PKCS7_verify(), por lo que cualquiera que ejecute una de esas compilaciones upstream tiene la corrección sin que se le haya informado. En las distribuciones downstream es peor. El estándar documentado de Red Hat [https://access.redhat.com/security/updates/backporting] es hacer un backport en lugar de cambiar la versión, por lo que un paquete parcheado sigue informando la versión desde la cual fue construido. Lo que normalmente resuelve eso es el aviso y la alimentación OVAL, ambos vinculados a los nombres de los CVE. Aquí no hay ningún CVE al cual vincularse. Eso deja el registro de cambios del paquete o al mantenedor: pregunta si basaron su versión en la versión del 9 de junio o si tomaron el parche, que es la solicitud de extracción 30792 [https://github.com/openssl/openssl/pull/30792] para master y 4.0, 30793 [https://github.com/openssl/openssl/pull/30793] para 3.6, 3.5 y 3.4, y 30794 [https://github.com/openssl/openssl/pull/30794] para 3.0. Si tú mismo compilas OpenSSL, actualiza a la versión listada y reinicia cualquier cosa que haya cargado la versión antigua. La corrección cubre solo TLS. Caswell escribió en la solicitud de extracción que DTLS se dejó intacto porque hacerlo correctamente habría sido mucho más invasivo, y que el proyecto decidió no molestarse con ello por ahora. Al comparar el código fuente de OpenSSL en las etiquetas 3.6.2 y 3.6.3, se encontró que el archivo de saludo DTLS es idéntico byte a byte tras la corrección. En la 4.0.1, la versión más reciente, esa ruta todavía dimensiona su búfer según la longitud que declara el par. OpenSSL no ha clasificado esa ruta ni se ha comprometido a corregirla. Las notas de lanzamiento, el registro de cambios y la página de vulnerabilidades no dicen nada al respecto. La solicitud de extracción sí lo hace.

Fuente:
THN