Hace pocos días se dio a conocer información sobre una vulnerabilidad crítica (CVE-2024-6387) que fue identificada en OpenSSH por los investigadores de Qualys, y se menciona que está permite la ejecución remota de código con privilegios de root sin necesidad de autenticación.

Los investigadores de Qualys bautizaron a la vulnerabilidad como «regreSSHion», y se presenta en la configuración predeterminada de OpenSSH a partir de la versión 8.5 en sistemas que utilizan la biblioteca estándar Glibc.

¿Qué es regreSSHion y como afecta a OpenSSH?

En la publicación de blog de Qualys, se menciona que regreSSHion es resultado de un cambio regresivo incluido en OpenSSH 8.5, que provoca una condición de carrera en el manejo de señales en sshd. Esta regresión eliminó la protección contra una antigua vulnerabilidad, la cual era de carácter teórico (en la práctica era muy complejo o casi imposible poder explotarla).

Durante el desarrollo de OpenSSH 8.5, por error, se eliminó el bloque «#ifdef DO_LOG_SAFE_IN_SIGHAND» de la función sigdie(), que se ejecuta directamente desde el controlador SIGALRM. El controlador SIGALRM se ejecuta de forma asincrónica en sshd si el cliente no se ha autenticado dentro del tiempo límite de espera de la conexión (LoginGraceTime, predeterminado en 120 segundos).

Método de explotación

El ataque se basa en el hecho de que el controlador de señales llama a funciones que no son seguras para el procesamiento asincrónico de señales, como syslog(). En Glibc, la función syslog() no está diseñada para ser utilizada en manejadores de señales ejecutadas asincrónicamente.

La activación de la señal SIGALRM interrumpe la ejecución de cierto código en sshd, lo que puede llevar a una violación del estado de ejecución. El objetivo del exploit es crear condiciones para interrumpir el código deseado en el momento adecuado. Por ejemplo, activar SIGALRM durante la ejecución de malloc o free puede corromper las estructuras internas de malloc. OpenBSD no se ve afectado por esta vulnerabilidad porque, en lugar de syslog(), el controlador de señales SIGALRM llama a la función syslog_r(), especialmente diseñada para ejecución asincrónica.

Los investigadores de Qualys mencionan que, el ataque resulta más sencillo y requiere menos tiempo en sistemas sin ASLR o en distribuciones que usan una versión modificada de OpenSSH que deshabilita la re-aleatorización de ASLR por conexión.

La vulnerabilidad fue demostrada en un sistema de 32 bits con Glibc y protección ASLR (aleatorización del espacio de direcciones) habilitada. Un ataque exitoso en un entorno controlado tomó entre 6 y 8 horas, durante las cuales se realizaron conexiones continuas al servidor al máximo ritmo permitido por la configuración de sshd.

Aunque no se puede descartar un ataque a sistemas de 64 bits, aún no se ha desarrollado un exploit funcional para estos sistemas. Se espera que atacar sistemas de 64 bits tome considerablemente más tiempo, aunque no más de una semana.

Mitigación y solución

Se menciona que OpenSSH en OpenBSD no se ve afectado por esta vulnerabilidad, ya que desde 2001 este sistema ha utilizado un mecanismo de protección que bloquea este tipo de ataques. En otros sistemas basados en bibliotecas estándar distintas a Glibc, es teóricamente posible adaptar el método de ataque, aunque este aspecto aún no ha sido investigado por Qualys.

Adicionalmente, los sistemas con la biblioteca estándar Musl C no son vulnerables a esta técnica de explotación, ya que en musl la función syslog() no utiliza asignación de memoria dinámica al formatear la salida mediante printf() y no invoca a la función localtime() al adjuntar la hora a los registros de mensajes enviados.

Finalmente, cabe mencionar que la vulnerabilidad se ha solucionado en la versión parcheada OpenSSH 9.8, que fue publicada hace poco y que estaremos hablando de ella en un artículo próximo. Como solución alternativa para mitigar la vulnerabilidad, se puede configurar el parámetro «LoginGraceTime=0» en el archivo sshd_config. No obstante, deshabilitar el tiempo de espera puede facilitar la iniciación de un ataque de denegación de servicio si se establecen numerosas conexiones que excedan los límites especificados mediante el parámetro MaxStartups.

Si estás interesado en poder conocer más al respecto, te invito a que consultes la publicación de Qualys en el siguiente enlace.