RegreSSHion: ejecución remota de código (RCE) en el servidor OpenSSH de sistemas Linux basados en glibc

Resumen

• Se descubrió una vulnerabilidad de seguridad en OpenSSH: Se encontró una vulnerabilidad de ejecución remota de código (RCE) en el servidor OpenSSH (sshd) causada por una condición de carrera en el manejador de señales. Esta vulnerabilidad afecta a sshd en la configuración predeterminada.
• Origen de la vulnerabilidad: Esta vulnerabilidad es una regresión de CVE-2006-5051, reportada en 2006, y fue causada por un cambio de código introducido en OpenSSH 8.5p1 en octubre de 2020.
• Impacto de la vulnerabilidad: Puede explotarse de forma remota en sistemas Linux basados en glibc, afecta el código privilegiado de sshd y permite la ejecución remota de código con privilegios de root.
• Método de explotación: Para explotar esta vulnerabilidad, es necesario encontrar una ruta de código específica e interrumpirla en el momento adecuado. Para ello, se parte de versiones antiguas de OpenSSH y se extiende el enfoque hasta versiones recientes.
• Parche y mitigación: Se proporcionan un parche y métodos de mitigación para resolver la vulnerabilidad.

SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, 2005)

Teoría

• Manejador de SIGALRM: El manejador de SIGALRM de esta versión llama a packet_close(), que a su vez llama a buffer_free(), y este llama a xfree() y free(). free() no es seguro para señales asíncronas.
• Análisis del código de malloc: Al analizar el código de malloc, se encontró una ruta explotable cuando una llamada a free() es interrumpida por SIGALRM y luego vuelve a invocarse dentro del manejador de SIGALRM.

Práctica

• Método de ataque: Se logra la ejecución remota de código al interrumpir una llamada a free() en el código que analiza una clave pública DSA y explotarla dentro del manejador de SIGALRM.
• Ganar la condición de carrera: Para ganar esta condición de carrera, se requieren alrededor de 10,000 intentos y, en promedio, toma cerca de una semana.

Temporización

• Estrategia de temporización: Para minimizar la latencia de red, se envía el último byte en el último instante y se ajusta el tiempo siguiendo el tiempo de ida y vuelta. Esto aumenta la probabilidad de ganar la condición de carrera.

SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, 2006)

Primera teoría

• Manejador de SIGALRM: El manejador de SIGALRM de esta versión no llama a packet_close(), y como la función malloc siempre bloquea, se necesita otra solución.
• Uso de PAM: Se descubrió que pam_end() de PAM no es seguro para señales asíncronas, y se exploró una ruta para explotarlo.

Segunda teoría

• Análisis de pam_start(): Si pam_start() es interrumpido, la estructura PAM puede quedar en un estado inconsistente, lo que permite explotarla dentro del manejador de SIGALRM.
• Técnica House of Mind: Para el ataque se utiliza la técnica House of Mind para manipular asignaciones de memoria y lograr ejecución remota de código con privilegios de root.

Práctica

• Método de ataque: Se manipulan asignaciones de memoria usando nombres de usuario largos y se incrementa la probabilidad de ganar la condición de carrera mediante múltiples llamadas a pam_start().

Temporización

• Estrategia de temporización: Se reutiliza la estrategia de temporización usada en la versión anterior de Debian para aumentar la probabilidad de ganar la condición de carrera. En promedio toma de 1 a 2 días.

SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2 (Debian 12.5.0, 2024)

Teoría

• Manejador de SIGALRM: El manejador de SIGALRM de esta versión llama a syslog(), que a su vez invoca funciones que no son seguras para señales asíncronas.
• Análisis de glibc: syslog() de glibc llama a malloc, que no es seguro para señales asíncronas. Además, la función malloc de glibc no bloquea cuando es de un solo hilo.

Parche y mitigación

• Parche: La vulnerabilidad fue reportada a los desarrolladores de OpenSSH y se proporcionó un parche para resolverla.

Opinión de GN⁺

• Importancia de la seguridad: OpenSSH es un software de seguridad extremadamente importante, y esta vulnerabilidad es un caso muy poco frecuente.
• Dificultad de explotación: Explotar esta vulnerabilidad requiere una temporización muy precisa y muchos intentos.
• Soluciones alternativas: Además de OpenSSH, existen varias soluciones de seguridad, y es recomendable usarlas en conjunto.
• Desafío técnico: Esta investigación exige un nivel técnico muy alto y puede servir de gran inspiración para investigadores de seguridad.
• Mitigación de la vulnerabilidad: Es importante aplicar los parches de seguridad más recientes y reforzar la configuración de seguridad.

[GN⁺]

Opiniones de Hacker News

• La corrección del RCE se publicó de forma "discreta" hace casi un mes

  • Cuando PerSourcePenalties está habilitado, sshd(8) monitorea el estado de salida de los procesos hijo de sesión de preautenticación
  • Registra penalizaciones cuando un cliente intenta autenticarse repetidamente o cuando sshd falla
  • Este parche cambia la arquitectura del binario para eliminar una vulnerabilidad específica y mitigar toda una clase de exploits

• En el diff que introdujo el bug, la función fue refactorizada de la siguiente manera

  • Función original: sigdie(const char *fmt,...)
  • Función refactorizada: sshsigdie(const char *file, const char *func, int line, const char *fmt, ...)
  • Faltó un #ifdef
  • Se podría haber evitado si más personas hubieran revisado el pull request

• Comentario interesante en las notas de lanzamiento de OpenSSH

  • Se demostró un exploit exitoso con ASLR en sistemas Linux/glibc de 32 bits
  • Parece probable que también sea posible en sistemas de 64 bits

• OpenBSD no se ve afectado por esta vulnerabilidad porque el manejador de SIGALRM llama a syslog_r()

  • Usa una versión de syslog() segura para señales asíncronas
  • Fue necesario un refactor para minimizar la cantidad de código dentro del manejador de señales

• Al revisar syslog(3) de musl, no parece explotable fácilmente, a diferencia de glibc

  • Todo está en el stack o en variables estáticas protegidas contra reentrada

• Ya salió un parche para FreeBSD, y como no usa glibc, es muy probable que no esté afectado

• Configurar LoginGraceTime 0 en el archivo sshd_config puede mitigar el problema

  • Esto lo hace vulnerable a ataques de denegación de servicio, pero evita la ejecución remota de código

• Ya salió un parche para Debian 12, y Debian 11 no está afectado

• Se proporcionan enlaces a las notas de lanzamiento de OpenSSH y al parche mínimo

• Desde una postura independiente, encontrar una sola vulnerabilidad debería ser suficiente

  • Sin embargo, suele pasar que la gente solo lo toma en serio o paga recompensas cuando se encuentra toda la cadena