Imagina que alguien puede mandar un paquete de once bytes — sí, once, menos que un tweet — y tu servidor empieza a tragarse memoria como si no hubiera mañana hasta que se cae. No es ciencia ficción. Es HollowByte, un bug que el equipo de seguridad de Okta encontró en OpenSSL y que estuvo escondido ahí por quién sabe cuánto tiempo.
Un header que miente y un malloc que cree todo
El problema está en cómo OpenSSL maneja el handshake TLS. Cuando llega un ClientHello, el servidor lee un header de 4 bytes que dice «oye, el mensaje que viene es de X tamaño». Y OpenSSL, inocente, hace un malloc() con ese número antes de que llegue cualquier dato real. El atacante manda once bytes con un número inflado, el servidor reserva hasta 131 KB, y luego se queda esperando datos que nunca van a llegar. El thread se bloquea. La memoria queda reservada. Y si repites esto con tamaños aleatorios, fragmentas el heap de una forma que ni reiniciando el proceso se arregla — bueno, sí se arregla reiniciando, pero ese es el punto: tienes que matar el proceso.
Lo que me da más rabia es que esto no es un exploit sofisticado. No necesitas credenciales, no necesitas un 0day de esos que cuestan millones. Solo necesitas entender que un sistema confió en un número que venía en un paquete de red. Es el equivalente a que un cartero te diga «traigo un paquete de 50 kilos» y tú desocupes el living entero antes de ver si realmente trae algo.
El silencio administrativo
Aquí viene la parte que a mí personalmente me preocupa más. OpenSSL no lanzó un CVE. Lo trató como un «hardening fix» y lo metió silenciosamente en la versión 4.0.1, con backports a 3.6.3, 3.5.7, 3.4.6 y 3.0.21. Sin alharacas, sin advisory de seguridad, sin mailing list alarmando a medio mundo. Si tú no lees los release notes con lupa, no te enteraste.
Y eso es un problema porque OpenSSL está en todas partes. Apache, NGINX, Node.js, Python, Ruby, PHP, MySQL, PostgreSQL. Es la base de la infraestructura de internet y la respuesta del equipo es «sí, lo arreglamos, pero no hicimos ruido porque no queremos que nadie se asuste». Perdón, pero si tu software es crítico para medio planeta, la transparencia no es opcional. Un DoS que mata servidores en producción no es un detalle menor.
¿Qué tan grave es realmente?
Los muchachos de Okta hicieron pruebas. En un servidor con 1 GB de RAM, el proceso fue OOM-killed con 547 MB de memoria fragmentada. En una máquina de 16 GB, lograron congelar el 25% de la RAM total. Y lo peor: el ataque vuela por debajo de los límites de conexiones normales, así que tus defensas estándar tipo rate-limiting no te salvan. Es un Slowloris pero peor, porque Slowloris al menos puedes mitigar con timeouts. Esto te deja la memoria hecha pedazos incluso después de que el atacante se desconecta.
La solución técnica es razonable: en vez de confiar en el header, OpenSSL ahora crece el buffer incrementalmente, solo a medida que llegan bytes reales. Si no llega nada, no cuesta nada. Es la clase de fix que debió estar desde el principio, pero bueno, mejor tarde que nunca.
Mi opinión
Este tipo de bugs me recuerda por qué me pongo nervioso cuando la gente dice «actualiza solo cuando sea necesario». Si no sabes qué estás corriendo, no sabes qué te pueden hacer. Y con OpenSSL, la mayoría de las empresas no tiene idea de qué versión tienen en cada servidor, cada contenedor, cada lambda que alguien desplegó hace tres años y nadie ha tocado desde entonces.
Mi consejo: actualiza. No mañana, no la próxima semana. Ahora. Y si tu proveedor de hosting o tu distro no ha sacado el parche, presiona. Porque once bytes no suenan a mucho, pero cuando esos once bytes pueden tumbar tu producción, son más que suficientes.
Fuente de inspiración: OpenSSL HollowByte: A DoS Hiding in 11 Bytes
