Llegamos a ustedes gracias a:



Alertas de Seguridad

5 cosas que debe saber sobre Stack Clash

Para asegurar su ambiente compartido en Linux

[31/07/2017] La vulnerabilidad que implica el Stack Clash en sistemas Linux, Solaris y BSD permitiría a los atacantes ganar privilegios de raíz y tomar control absoluto de la máquina, advirtieron los investigadores de Qualys el mes pasado. Los proveedores y administradores que son anfitriones de ambientes compartidos deben prestar mucha atención a esta falla, puesto que un usuario afectado puede resultar en que todos los demás usuarios en el mismo servidor también sean perjudicados.

El Stack Clash abarca un conjunto de vulnerabilidades de escalada de privilegios (CVE-2017-1000364, CVE-2017-1000365 y CVE-2017-1000367, por mencionar algunos ejemplos), afectando el stack de las aplicaciones, una región de la memoria que alberga los datos de corto plazo para las aplicaciones, creciendo automáticamente según sea necesario. Cuando el stack de la aplicación alcanza un tamaño demasiado grande, puede acercarse mucho al heap, la región de la memoria que aloja la información como archivos que están siendo vistos y editados. Los atacantes pueden aprovecharse de la proximidad de ambos para confundir a la aplicación y hacer que ésta sobrescriba partes del stack y del heap. Hacer eso implica el secuestro del flujo de ejecución dentro de la aplicación.

"Nuestra explotación hace que el stack crezca, saltando por encima de protecciones y llegando a áreas de memoria donde no deberíamos ser capaces de lograr ejecutar el código, afirma Jimmy Graham, director de gestión de producto en Qualys.

El atacante gana los privilegios del programa secuestrado. Tampoco se trata solo de aplicaciones ordinarias. Estos son programas confiables a nivel de sistemas como SUID en las distribuciones Linux, como Debian Ubuntu y CentOS; ld.so, y binarios de raíz SUID en Debian, Ubuntu, Fedora y CentOS; y rhs en Solaris. Si el programa tiene privilegios de raíz, el atacante toma el control de todo el sistema como administrador. "Esta es una manera directa de llegar a la raíz después de haber conseguido un acceso a nivel de usuario, afirma Graham.

La vulnerabilidad está presente en sistemas basados en Unix con arquitecturas i386 y amd64. Las distribuciones de Linux afectadas incluyen a Red Hat, Debian, Ubuntu, SUSE, CentOS y Gentoo. Solaris es propiedad de Oracle. FreeBSD, OpenBSD y NetBSD también se ven impactadas. Qualys ha estado trabajando con distribuciones y proveedores desde mayo para arreglar las vulnerabilidades, y las actualizaciones justo están empezando a ser lanzadas. Los administradores necesitan actuar de inmediato para actualizar las máquinas afectadas con actualizaciones de seguridad.

Se requiere de atención inmediata, especialmente sabiéndose que los sistemas que se basan en Unix son utilizados predominantemente en ambientes de servidor. Qualys no investigó productos de Microsoft o de Apple, y Graham no pudo decir qué tipo de efecto tendría esta clase de vulnerabilidad en aquellos sistemas.

Los sistemas que deben cumplir con regulaciones específicas, o que contienen información crucial deberían ser la prioridad. Los proveedores y administradores alojados que gestionan ambientes compartidos deben asegurarse de que sus sistemas estén actualizados. Si el usuario tiene acceso de shell al servidor, como suelen tenerlo en ambientes multiusuario, los atacantes tienen la posibilidad de comprometer a ese usuario, y usar Stack Clash para secuestrar las aplicaciones que operan en ese espacio de usuario. En ese punto, los atacantes pueden saltar a otros espacios de usuario en ese ambiente compartido.

A continuación, se encuentran cinco medidas para considerar a la hora de evaluar el riesgo que el Stack Clash representa para la organización.

1. No subestime el daño que puede generar una explotación local

Los investigadores de Qualys no encontraron una explotación remota, pero tampoco se pudo descartar. Esa es una distinción importante. Solo porque ellos no la encontraron, no significa que no sea posible. Todo depende de cómo fue construido el programa. Qualys observó el servidor de correo Exim en Debian, y fue "pura suerte que no haya sido explotable remotamente, afirma Graham.

Asimismo, los atacantes rara vez usan solo una vulnerabilidad durante un ataque, puesto que obtienen mejores resultados juntándolas en una cadena. El Stack Clash es una herramienta poderosa en su arsenal mientras se mueven lateralmente a través de una red comprometida. Ellos pueden usar una explotación remota u otros medios para obtener el punto de apoyo dentro de la red, pero una vez que se encuentran en una máquina vulnerable, pueden usar el Stack Clash para ganar acceso a la raíz y realizar otras acciones. Por ejemplo, una vulnerabilidad en sudo arreglada recientemente (CVE-2017-100367) podría combinarse con el Stack Clash para operar un código arbitrario con los privilegios más altos. Solo por el hecho de que el servidor no cuente con acceso remoto, no resulta ser una razón lo suficientemente buena para hacer que actualizarlo tenga una menor prioridad.

2. Las páginas guardianas de stack evitan este tipo de ataques

En realidad, la mala noticia es que no los evitan. De hecho, el Stack Clash pasa por alto completamente a las páginas guardianas del stack. El concepto detrás del Stack Clash ha sido bien entendido desde el 2005 y después de que se explotara en el 2010 (CVE-2010-2240), el núcleo de Linux añadió páginas guardianas del stack para mitigar esa clase de ataques. La página guardiana actúa como un divisor entre el stack y el heap. Sin embargo, los investigadores de Qualys pudieron pasar por alto completamente a las páginas guardianas debido a que las aplicaciones no fueron construidas con suficientes chequeos de protección del stack en sus códigos.

"Desafortunadamente, una página guardiana del stack de unos pocos kilobytes es insuficiente. Si el puntero de stack 'salta' sobre la página guardiana -si se mueve del stack hacia otra región de la memoria sin acceder a la página guardiana- no surge ninguna falla de excepción de página y el stack se extiende dentro de la otra región de la memoria, escribieron los investigadores de Qualys en la asesoría. "Nosotros mostramos que los conflictos de stack están ampliamente esparcidos en el espacio del usuario y son explotables a pesar de la página guardiana del stack.

El tamaño de la página guardiana del stack debería ser incrementado a un mínimo de 1MB como una solución de corto plazo hasta que se apliquen las actualizaciones.

3. El Stack Clash no afecta las máquinas virtuales y a los contenedores, pero...

Sí y no. El Stack Clash es una explotación local en el espacio del usuario y no en el mismo sistema operativo. Esto significa que, si el aislamiento de seguridad del contenedor, como espacios nombrados y cgroups, se encuentran funcionando apropiadamente, el atacante puede llegar a la raíz dentro del contenedor, pero no podría escapar del contenedor para ganar el privilegio de raíz en la máquina. No debería ser posible saltar de chroot a chroot, pero solo si esa segmentación fue realizada apropiadamente.

Lo mismo aplica en las máquinas virtuales (VMs). El atacante puede secuestrar el programa que está operando en un sistema operativo vulnerable dentro de una máquina virtual, pero los privilegios elevados van a permanecer dentro de los confines de la máquina virtual misma. Los atacantes tendrían que encadenar el Stack Clash con otra vulnerabilidad que pudiera salir del contenedor o máquina virtual.

Sin embargo, existe una advertencia, una muy grande. Muchas organizaciones se apoyan en las máquinas virtuales para hacer que los despliegues y la administración sean más simples. Si instalan una máquina virtual y después instalan un ambiente de múltiples miembros adentro de ésta, el Stack Clash afectaría a todos los usuarios dentro de esas máquinas virtuales o contenedores, afirma Gounares. A esas alturas, ya no importa si el sistema subyacente no tiene sistema operativo, es una máquina virtual o contenedor, ya que un usuario que ha sido comprometido dentro del ambiente hará que otros usuarios sean perjudicados también.

También vale la pena resaltar que el Stack Clash es difícil de darse en ambientes de 64 bits, y los contenedores de Docker operan en 64 bits de manera predeterminada. También existe una opción de Docker para limitar el tamaño de la imagen del stack en el contenedor mediante la adición de la bandera -ulimit stack=[tamaño]. Asegúrese que el valor del tamaño no sea tan bajo, pues eso podría afectar el comportamiento normal de la aplicación. Instalar la opción asegurará que "el stack nunca alcanzará al heap, afirma Daniel Shapira, investigador de Twistlock.

4. Los datos están cifrados, así que incluso si el servidor es afectado, los datos están seguros

Absolutamente no. Si los datos almacenados en los servidores están cifrados, felicitaciones. Pero los ataques de Stack Clash pueden seguir teniendo éxito para acceder a la información cifrada si la aplicación que es secuestrada es la que maneja los datos. Con acceso de raíz, los atacantes tienen un control completo de la caja, y pueden acceder a la aplicación capaz de descifrar los datos.

5. Use la solución alternativa, pero esta no es a prueba de balas

Los administradores deben tener cuidado cuando apliquen actualizaciones de software a los servidores, especialmente cuando las actualizaciones tienen que ser probadas cuidadosamente para asegurar que no existan problemas potenciales. Reiniciar los servidores de producción también requiere de mucho planeamiento avanzado. Como solución alternativa, los administradores pueden decidir limitar hasta qué tamaño puede crecer el stack instalando los recursos RLIMIT_STACK y RLIMIT_AS de usuarios locales y servicios remotos, pero eso trae su propio conjunto de desafíos.

Si se establece un límite de stack que es demasiado bajo, los programas colapsarán porque las aplicaciones no pueden pasar los parámetros que necesitan durante el curso de las operaciones normales. Se requerirá que las pruebas encuentren la cantidad óptima que necesita la aplicación para calcular el máximo y descubrir eso de manera precisa es difícil, pues muchos de los casos de borde necesitan ser probados.

Existe la posibilidad de que las explotaciones aún sean capaces de evadir la solución alternativa. "Use esta solución alterna bajo su propio riesgo. Lo más probable será que sus límites no sean lo suficientemente bajos para resistir todos los ataques, escribió Qualys en la asesoría. Algunas de las explotaciones construidas por Qualys asignaron solo 137MB de memoria heap y casi ninguna memoria stack, y ese tipo de límite es demasiado bajo para las aplicaciones modernas.

Reconstruir y volver a instalar la biblioteca dinámica ld.so y recopilar a todos los programas usando la opción fstack-check de ggc, evitaría que el puntero del stack se mueva hacia otras regiones de memoria. Esto requerirá que todos los programas sean recompilados -una tarea que sin duda alguna es costosa. Pero evitaría por completo al Stack Clash.

Haga aleatoria la memoria para hacer que los ataques tomen más tiempo

Las pruebas de concepto hechas por Qualys siguieron cuatro pasos secuenciales, que incluyen: Enfrentar al stack con otra región de memoria, correr el puntero del stack hacia el inicio del stack, saltar encima de la página guardián del stack, y escribir a la región de la memoria para aplastar el stack o a otra región de la memoria. En el último paso, el de escribirle a la región de la memoria, Qualys fue capaz de acceder a la ASLR (Address Space Layout Randomization), por medio de fuerza bruta, porque esta solo utilizó ocho bits de entropía.

El Stack Clash funciona porque se apoya en detalles predecibles del sistema que tenga en la mira, como dónde se almacenan los datos y cómo se comportará el código, afirma Gounares. Cuando los detalles se encuentran en lugares esperados o pueden adivinarse con facilidad, los atacantes pueden usar fuerza bruta para llegar a la información que necesitan saber. Mediante la prueba de todas las combinaciones posibles, la explotación de Qualys se demoró solo cinco horas en acceder a la ASLR por medio de fuerza bruta.

"Si el atacante no conoce y no puede adivinar los detalles de sus víctimas objetivo, los ataques como el Stack Clash se vuelven imprácticos -incluso si las fallas subyacentes de la explotación siguen existiendo, afirma Gounares.

Todos deberán actualizar sus servidores para lidiar con el Stack Clash y, considerando el tipo de daño posible, todos deberían hacerlo pronto, antes de que la ola de ataques empiece a tumbar a los sistemas vulnerables.