En reciente post de TheHackersNews, se describe como unos investigadores de seguridad han repostado una vulnerabilidad de casi 10 años de antiguedad afecta a todos los sistemas operativos basados en Unix, esto incluye entre otros a Solaris, todas las distribuciones de Linux sin excepción y a la familia BSD (OpenBSD, NetBSD, FreeBSD). Lo peligroso de esta vulnerabilidad es que puede ser explotada para obtener privilegios de root y con ello hacerse del control absoluto del sistema.
El nombre dado a esta vulnerabilidad es Stack Clash, la vulnerabilidad (CVE-2017-1000364) que se encuentra en la forma como se asigna la memoria en la pila para los binarios del espacio de usuario.
¿En qué consiste la vulnerabilidad?
La explicación es simple. Cada programa utiliza una región de memoria especial llamada pila (stack en inglés), que se utiliza para almacenar datos a corto plazo. Se expande y se contrata automáticamente durante la ejecución de cualquier programa, dependiendo de las necesidades del programa.
Según los investigadores de Qualys, que descubrieron y reportaron este error, un programa malintencionado puede intentar usar más espacio de memoria que el disponible en la pila, lo que podría desbordar la memoria, lo que haría que colisione o choque con regiones de memoria cercanas, sobrescribiendo su contenido.
Además, se ha encontrado que un exploit de Stack Clash también puede pasar por alto el stack guard-page, una protección de gestión de memoria introducida en 2010, después de que este problema fuera explotado en 2005 y 2010.
¿Esta vulnerabilidad puede ser explotada remotamente?
La vulnerabilidad de Stack Clash requiere acceso local al sistema vulnerable para su explotación, pero los investigadores dijeron que podría explotarse remotamente dependiendo de las aplicaciones. Es decir usar una segunda vulnerabilidad que permita ganar privilegios de usuario local en un sistema y luego usar Stack Clash para escalar privilegios y obtener acceso root.
Otro escenario podría ser que un cliente malintencionado con una cuenta ftp de privilegios bajos de una empresa que ofrezca alojamiento web, que ejecuta un sistema vulnerable, podría explotar esta vulnerabilidad para obtener control sobre otros sitios web que se ejecutan en el mismo servidor, así como obtener acceso root de forma remota y ejecutar código malicioso directamente.
TheHackerNews tiene un post en el cual describe el caso de una compañía surcoreana de alojamiento web fue víctima de un ataque similar que se utilizó para infectar servidores Linux con un malware ransomware, haciendo que la compañía pagara más de 1 millón de dólares de rescate para recuperar sus archivos.
Más malas noticias.
Por si la divulgación de esta vulnerabilidad no fuera poco para los ya sufridos system administrators, ya existen actualmente disponibles en Internet 7 scripts de pruebas de concepto que explotan esta vulnerabilidad. Lo cuál significa que pronto estas herremientas de prueba terminaran convirtiendose en armas de hackeo.
Sin embargo, los investigadores aún no han publicado las hazañas y las pruebas de concepto, dando a los usuarios y administradores tiempo suficiente para parchear sus sistemas antes de divulgar los scripts de Stack Clash al público.
Los scripts de pruenas de concepto siguen cuatro pasos, que incluyen el ‘Clash’ (choque) de la pila con otra región de memoria, ejecutando el puntero de pila que está apuntando al inicio de la misma, ‘Jump’ (salto) sobre la página de guardia de la pila y ‘Smashing’ (rompiendo) la pila u otras regiones de memoria.
Entre las distribuciones y sistemas afectados por Stack Clash se incluyen:
- Sudo en Debian, Ubuntu y CentOS
- Ld.so y la mayoría de los binarios SUID-root en Debian, Ubuntu, Fedora y CentOS
- Exim en Debian
- Rsh en Solaris 11 y versiones superiores
- Red Hat Enterprise
La compañía también cree que otros sistemas operativos, como Microsoft Windows, OS X/macOS de Apple y el sistema operativo Android de Google basado en Linux, podrían también ser vulnerables a Stack Clash, aunque aún no se ha confirmado.
Ya existin actualizaciones disponibles para esta vulnerabilidad así que se recomienda actualizar inmediatamente. De no ser posible esto (ya que no podemos reiniciar el servidor) hay una forma de mitigar esto limitanto el parámetro del kernel RLIMIT_STACK tanto para usuarios locales como remotos.