RegreSSHion: El fantasma de una vulnerabilidad de hace 18 años amenaza a millones de servidores Linux

¿Te imaginas que la puerta principal de tu casa, esa con cerradura de alta seguridad que lleva años protegiéndote, tuviera una grieta invisible desde 2006 que permite a cualquiera entrar sin llave? Eso es exactamente lo que ha ocurrido en el corazón del sistema operativo que mueve Internet.

Recientemente, investigadores de seguridad descubrieron una vulnerabilidad crítica en OpenSSH —el estándar de facto para la administración remota segura de servidores Linux— bautizada como RegreSSHion (CVE-2024-6387). Lo más llamativo no es solo que permita a un atacante no autenticado obtener acceso root total sobre un servidor sin necesidad de contraseña ni clave SSH, sino que este fallo es una regresión de un bug corregido en 2006. Un despiste en el código reintrodujo la brecha casi dos décadas después.

Anatomía de una condición de carrera: ¿Cómo funciona RegreSSHion?

Para entender el problema sin morir en el intento (o en un mar de punteros de C), tenemos que echar un vistazo a cómo gestiona OpenSSH los tiempos de espera.

Cuando un cliente intenta conectarse vía SSH a un servidor Linux, el demonio sshd le concede un tiempo límite para autenticarse (definido por la directiva LoginGraceTime, que por defecto suele ser de 120 segundos). Si el usuario no se autentica dentro de ese plazo, el servidor genera una interrupción mediante la señal SIGALRM para cerrar la conexión de forma limpia. Y aquí es donde empieza la magia negra de la ciberseguridad.

El controlador de la señal SIGALRM en las versiones afectadas de OpenSSH llamaba de forma insegura a funciones como syslog(). El problema reside en que syslog() utiliza internamente malloc() y free() para gestionar memoria dinámica, y estas funciones no son reentrantes (async-signal-safe).

Si la señal de alarma interrumpe el proceso justo en el microsegundo exacto en que la memoria principal del programa estaba ejecutando otra operación de asignación, la estructura interna del montón (heap) queda corrupta.

[Cliente SSH] ---> Conexión iniciada ---> [Temporizador: LoginGraceTime]
                                                    |
                                      (Transcurren 120 segundos)
                                                    |
[Servidor sshd] <--- Señal SIGALRM <----------------+
       |
       +--> Llama a syslog() [Función NO segura en señales]
       |
       +--> Interrumpe gestión de memoria (malloc/free)
       |
       +--> ¡Explotación del Heap / Condición de Carrera! ---> [Acceso Root]

Explotar esta race condition o condición de carrera implica enviar miles de conexiones sincronizadas al milisegundo para forzar la corrupción de memoria en el instante preciso. No es una tarea trivial que un script kiddie pueda ejecutar en cinco minutos desde un cibercafé, pero en un laboratorio o bajo un ataque dirigido, permite la ejecución remota de código arbitrario con privilegios de root.

Alcance, sistemas afectados y la importancia de la glibc

El impacto es masivo debido a la omnipresencia de OpenSSH en la infraestructura global. Sin embargo, no todos los sistemas reaccionan igual.

• Sistemas afectados: La vulnerabilidad afecta principalmente a distribuciones Linux basadas en la biblioteca estándar C de GNU (glibc). Versiones de OpenSSH desde la 8.5p1 hasta la 9.7p1 son vulnerables.
• Sistemas no vulnerables: Curiosamente, las versiones de OpenSSH en OpenBSD no se ven afectadas gracias a que su implementación de seguridad prohíbe llamadas no seguras en los controladores de señales desde hace años.

Nota técnica: Aunque la explotación en arquitecturas de 32 bits puede llevar un par de horas debido al espacio de direcciones más reducido, en sistemas de 64 bits la protección ASLR (Address Space Layout Randomization) dificulta el ataque, requiriendo millones de intentos para tener éxito. Aun así, en ciberseguridad, «difícil» nunca significa «imposible».

Solución y mitigación: Apagando el incendio en producción

Afortunadamente, la comunidad open source reaccionó con la rapidez que la situación requería. La solución definitiva es actualizar OpenSSH a la versión 9.8p1 o posterior, donde el controlador de la señal ha sido completamente refactorizado para evitar llamadas a funciones no seguras.

Si estás gestionando servidores y por razones de compatibilidad no puedes actualizar el paquete inmediatamente, existe una solución temporal tan sencilla como efectiva:

1. Abre el archivo de configuración del servicio SSH en tu servidor:

   sudo nano /etc/ssh/sshd_config

2. Modifica o añade la directiva LoginGraceTime estableciendo su valor a cero:

   LoginGraceTime 0

3. Reinicia el servicio sshd:

   sudo systemctl restart sshd

Al fijar LoginGraceTime 0, desactivas el tiempo de espera de autenticación. Esto elimina la activación de la señal SIGALRM y cierra la puerta a la condición de carrera (aunque deja el servidor ligeramente más expuesto a ataques de denegación de servicio si un atacante agota los sockets abiertos).

RegreSSHion nos deja una lección valiosa sobre la complejidad del software moderno: incluso en proyectos hiperauditados y con los más altos estándares de calidad, un pequeño cambio de código o la reintroducción de una rutina antigua puede reabrir agujeros del pasado. ¿Ya has actualizado tus servidores hoy o prefieres poner a prueba la paciencia de los cibercriminales? ¡Te leo en los comentarios!