El proyecto OpenSSL corrigió de manera discreta una vulnerabilidad de denegación de servicio (DoS) denominada «HollowByte», la cual permite a atacantes remotos agotar la memoria RAM de los servidores enviando cargas útiles de apenas 11 bytes durante el inicio de la conexión TLS.
Descubierta y reportada por el Red Team de Okta, la falla radica en cómo las versiones anteriores de la biblioteca OpenSSL gestionaban los encabezados del protocolo TLS. Al recibir un paquete inicial, el sistema leía un encabezado de 4 bytes que declaraba el tamaño del mensaje entrante y prereservaba hasta 131 KB de memoria en el heap antes de validar los datos o verificar la autenticación. Un atacante podía enviar un paquete malicioso de 11 bytes solicitando la asignación máxima de memoria y luego abandonar la conexión, dejando el proceso a la espera indefinidamente.
El impacto del ataque se agrava debido al comportamiento del asignador de memoria en la biblioteca GNU C (glibc). Aunque OpenSSL libera el búfer al cerrarse la conexión, glibc retiene esos bloques pequeños y medianos para uso futuro en lugar de devolverlos al sistema operativo. Al lanzar oleadas de conexiones con tamaños aleatorios, el atacante fragmenta severamente el heap y bloquea el uso de la memoria devuelta. En pruebas reales, ataques de este tipo lograron congelar el 25% de la RAM en servidores de 16 GB sin superar los límites habituales de tasa de conexiones (rate-limiting), obligando a reiniciar los servicios afectados para recuperar los recursos.
A pesar de su gravedad, OpenSSL catalogó la corrección como una mejora interna rutinaria, aplicando los parches en la versión 4.0.1 (y actualizaciones en las ramas 3.x) sin emitir un aviso formal de seguridad ni asignar un código CVE.
Nota elaborada con asistencia de IA. Fuentes verificadas y contenido editado por el equipo de Infosertec. [Conocé nuestro proceso editorial].