Detalles de la vulnerabilidad
Once bytes son suficientes para que un servidor OpenSSL sin parche reserve hasta 131 KB de memoria para un mensaje que nunca llega. En sistemas con glibc, esa memoria no se recupera hasta que el proceso se reinicia.
La corrección se incluyó en las versiones 4.0.1, 3.6.3, 3.5.7, 3.4.6 y 3.0.1 del 9 de junio, sin CVE, aviso ni entrada en el registro de cambios. El fallo reside en que OpenSSL confía en el tamaño declarado en el encabezado del mensaje TLS, asignando el búfer antes de verificar el cuerpo.
Cuando el atacante cierra la conexión, OpenSSL libera el búfer, pero glibc retiene fragmentos pequeños y medianos para reutilizarlos. Al variar el tamaño declarado en cada conexión, el asignador no puede reutilizar la memoria liberada, fragmentando el heap y aumentando la RSS permanentemente.
Las defensas estándar contra agotamiento de conexiones no detendrán este ataque, ya que no requiere alcanzar el límite de conexiones para congelar la memoria.
- Okta probó en NGINX: un servidor de 1 GB fue eliminado por OOM con 547 MB de memoria fragmentada.
- En un servidor de 16 GB, HollowByte inmovilizó el 25% de la memoria del sistema.
OpenSSL decidió tratar esto como un error o endurecimiento, no como una vulnerabilidad. Ni siquiera una clasificación de gravedad baja, que normalmente merece un CVE. No hay mención en las notas de publicación ni en el registro de cambios. El proyecto no ha explicado públicamente el motivo.
Impacto y remediación
La vulnerabilidad afecta a todas las versiones anteriores a las corregidas el 9 de junio de 2025 en las ramas 4.0, 3.6, 3.5, 3.4 y 3.0. Las distribuciones que retroportan parches pueden no estar actualizadas incluso si informan una versión anterior. Se recomienda actualizar a las versiones corregidas o aplicar los parches específicos (PR 30792 para master/4.0, 30793 para 3.6/3.5/3.4, 30794 para 3.0).
La corrección solo cubre TLS. DTLS no se parcheó, y en la versión 4.0.1 el código de DTLS sigue confiando en el tamaño declarado por el par. OpenSSL no ha clasificado esa ruta ni se ha comprometido a corregirla.
El Hacker News contactó a OpenSSL y Okta para obtener más información, pero hasta el 18 de julio no se había publicado código de explotación ni prueba de concepto pública.
