• 2 min de lectura
Un payload de 11 bytes puede agotar la memoria del servidor OpenSSL
Un payload de 11 bytes puede inflar la memoria de servidores OpenSSL vulnerables hasta que se agote. Ya hay versiones corregidas disponibles.

Imagen: BleepingComputer
Un payload de 11 bytes es suficiente para agotar la memoria de servidores OpenSSL vulnerables, según el Red Team de Okta. El fallo de denegación de servicio, apodado HollowByte, no requiere autenticación y no tiene un identificador de vulnerabilidad asignado.
El equipo de OpenSSL ha solucionado discretamente el problema y ha retroportado el cambio a versiones anteriores. Dado que OpenSSL sustenta TLS en gran parte de Internet, las organizaciones deberían actualizar a los paquetes parcheados cuanto antes.
Cómo funciona el ataque HollowByte
Durante el intercambio de handshake TLS, cada mensaje comienza con una cabecera de 4 bytes que contiene un campo de tres bytes que declara el tamaño de los datos siguientes. Las versiones de OpenSSL vulnerables asignan memoria para ese tamaño declarado antes de recibir y validar la carga útil.
Un atacante puede abrir una conexión TLS y enviar un mensaje de 11 bytes que afirma que llegará un cuerpo mucho mayor. El servidor asigna la memoria solicitada y luego espera indefinidamente datos que nunca llegan. Repetir el proceso a través de muchas conexiones puede consumir una memoria sustancial con relativamente poco tráfico de red.

Recomendado
Hombre de Florida acusado por malware en juegos de Steam que robó criptomonedas
El hilo trabajador se bloquea entonces, esperando indefinidamente datos que nunca llegarán.
OpenSSL finalmente libera los buffers cuando se cierran las conexiones, pero glibc suele reservar asignaciones pequeñas y medianas para reutilizarlas en lugar de devolverlas inmediatamente al sistema operativo. Al variar los tamaños declarados, los atacantes pueden impedir la reutilización, fragmentar gravemente el heap y aumentar el tamaño del conjunto residente (Resident Set Size) del servidor. Reiniciar el proceso es la única forma de recuperar completamente ese espacio.
Versiones de OpenSSL que contienen la corrección
OpenSSL está integrado en NGINX, Apache, Node.js, Python, Ruby, PHP, MySQL, PostgreSQL y la mayoría de las distribuciones Linux. Okta comprobó que los entornos NGINX de baja capacidad podían agotarse rápidamente, mientras que sistemas más grandes perdieron hasta un 25% de su memoria mientras el ancho de banda del ataque se mantenía por debajo de los umbrales de alerta de seguridad.
La corrección está incluida en OpenSSL 4.0.1 y fue retroportada a 3.6.3, 3.5.7, 3.4.6 y 3.0.21. Estas versiones aumentan los buffers solo a medida que llegan los datos, ignorando el tamaño declarado en la cabecera.
OpenSSL clasifica el cambio como una corrección de fortalecimiento, no como una vulnerabilidad de seguridad. No obstante, Okta recomienda actualizar inmediatamente los paquetes OpenSSL proporcionados por las distribuciones.
Security Editor
Sophia unpacks the invisible wars happening on our networks. Covering cybersecurity, privacy legislation, and cryptography, she exposes how our data is weaponized and defended. Before joining for(geeks), she spent years as a penetration tester. She's the reason the rest of the team uses physical security keys.
vía BleepingComputer


