La compañía Qualys ha identificado una vulnerabilidad crítica (CVE-2024-6387) en OpenSSH que permite la ejecución remota de código con privilegios de root sin necesidad de autenticación. La vulnerabilidad, apodada regreSSHion, se manifiesta en la configuración predeterminada a partir de la versión 8.5 de OpenSSH en sistemas con la biblioteca estándar Glibc.
La capacidad de realizar un ataque se demostró en un sistema de 32 bits con Glibc con la protección ASLR (aleatorización del espacio de direcciones) habilitada. Para llevar a cabo el ataque en condiciones de laboratorio, se requirieron de 6 a 8 horas, durante las cuales se el servidor establecieron continuamente conexiones con la máxima intensidad permitida en la configuración de sshd. La realización del ataque se facilita y requiere menos tiempo en sistemas sin ASLR o en distribuciones que utilizan OpenSSH modificado, en el que se desactiva la re-aleatorización de ASLR para cada conexión. Se decidió no publicar públicamente un prototipo funcional del exploit hasta que la vulnerabilidad sea eliminada ampliamente, pero hay suficiente descripción detallada sobre la naturaleza de la vulnerabilidad que hace que la aparición de exploits externos sea solo cuestión de tiempo.
No se descarta la posibilidad de realizar un ataque también en sistemas de 64 bits, pero un exploit funcional para esos sistemas aún no está listo. Se presume que llevar a cabo un ataque en sistemas de 64 bits tomará mucho más tiempo, pero no más de una semana. OpenSSH en OpenBSD no es vulnerable, ya que en este sistema se ha implementado desde 2001 un mecanismo de protección que bloquea este tipo de ataques. En otros sistemas basados en bibliotecas estándar diferentes de Glibc, teóricamente es posible adaptar el método para llevar a cabo un ataque (en Qualys este tema aún no ha sido estudiado).
La vulnerabilidad ha sido corregida en la publicación de hoy de OpenSSH 9.8 (parche). Se puede seguir la publicación de actualizaciones de paquetes en distribuciones en las páginas: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, ROSA, Gentoo, ALT Linux, Arch y FreeBSD. Como una solución alternativa para bloquear la vulnerabilidad en sshd_config se puede establecer el parámetro "LoginGraceTime=0", aunque la desactivación del tiempo de espera facilitará iniciar un ataque de denegación de servicio al establecer un gran número de conexiones que superen los límites establecidos a través del parámetro MaxStartups.
Una de las señales de un intento de ataque es la aparición en el registro de un gran número de entradas "Timeout before authentication".
La vulnerabilidad se originó a raíz de un cambio regresivo incluido en el lanzamiento de OpenSSH 8.5, que provoca una condición de carrera en el código de manejo de señales en sshd. La regresión llevó a la revocación de la protección contra una antigua vulnerabilidad CVE-2006-5051, que se manifestaba en versiones anteriores a OpenSSH 4.4 (2006) y tenía un carácter teórico.
Durante el desarrollo de OpenSSH 8.5, se eliminó por error el bloque "#ifdef DO_LOG_SAFE_IN_SIGHAND" de la función sigdie(), que se llama directamente desde el manejador SIGALRM.
El manejador SIGALRM se invoca en sshd de manera asíncrona si el cliente no ha completado la autenticación dentro del tiempo limitado por el tiempo de espera de conexión (LoginGraceTime, por defecto 120 seg). El ataque se basa en que el manejador de señales llama funciones que no son seguras en el manejo asíncrono de señales, como syslog(). La función syslog() en Glibc no está diseñada para ser utilizada en manejadores de señales que se ejecutan de manera asíncrona, ya que invoca funciones malloc() y free(). La activación de la señal SIGALRM, que interrumpe la ejecución de un código específico en sshd, puede provocar una violación del estado de ejecución, y la tarea del exploit consiste en crear condiciones para interrumpir el código necesario en el momento exacto de su ejecución. La vulnerabilidad no afecta a OpenBSD, ya que en lugar de syslog() desde el manejador de señales SIGALRM, se llama a la función syslog_r(), diseñada específicamente para ejecuciones asíncronas.
Fuente: opennet.ru
