Lo que ha salido a la luz con la nueva vulnerabilidad llamada StackWarp no es un fallo que se solucione con un parche del Sistema Operativo para Windows o Linux por desgracia, pero al mismo tiempo y por suerte, hay correcciones para ella en tres frentes actualmente. Estamos hablando de un problema de micro-arquitectura de AMD que se descubrió en julio del año pasado, incrustado en una optimización interna de los procesadores Ryzen o EPYC, y eso ya marca el tono, porque StackWarp afecta a la lógica que gestiona la pila de ejecución, una parte crítica de las CPU encargada de manejar llamadas y retornos de funciones de forma rápida y eficiente. El problema con esta vulnerabilidad es que StackWarp afecta a todas las arquitecturas Ryzen o EPYC, desde Zen 1 hasta Zen 5, así que el impacto es bastante amplio.

En los procesadores modernos de AMD, esa lógica es más grave si cabe, sobre todo en entornos de VM, ya que se incluye mecanismos internos no documentados que, bajo determinadas condiciones, pueden provocar que el puntero de pila (el llamado Stack Pointer) se desplace de forma incorrecta sin generar una excepción inmediata. Como es algo un poco complejo de explicar, para no hacer esto insufrible, daremos muchas cosas por sabidas dada la vulnerabilidad anterior, y al lío.

AMD StackWarp, la vulnerabilidad que con cambiar un bit deja a todas las CPU Ryzen o EPYC desde Zen 1 a Zen 5 expuestas con VM

El alcance real del problema no está en el PC común o en portátiles, para nada, ni en el usuario de escritorio, no por norma general, así que, en este caso, puedes estar medio tranquilo, salvo que uses VM, obvio. Donde sí que afecta es a procesadores basados en arquitecturas desde Zen 1 hasta Zen 5 en CPU de servidor, especialmente en plataformas AMD EPYC desplegadas en centros de datos, sobre todo, con Turin.

El contexto para entender el peligro es fácil de comprender, porque toca a la virtualización avanzada, o en entornos con múltiples máquinas virtuales compartiendo hardware físico y tecnologías de computación de alto rendimiento diseñadas para aislar una VM incluso del propio hipervisor.

El ataque no es ni remoto, por suerte, y requiere acceso privilegiado al sistema anfitrión donde el SMT de la CPU esté activada, de forma que dos hilos compartan el mismo núcleo físico. Desde The Register, han contactado con Ruiyi Zhang, investigador de CISPA, y ha deslizado las siguientes declaraciones a tenor de StackWarp:

"La vulnerabilidad puede explotarse mediante un bit de control no documentado previamente en el hipervisor. Un atacante que ejecute un hiperproceso en paralelo con la máquina virtual objetivo puede usar esto para manipular la posición del Stack Pointer dentro de la máquina virtual protegida".

De nuevo, un ataque lateral, otra vez, el SMT en tela de juicio, ¿hizo bien Intel en retirarlo? Pues…

Desde ese segundo hilo, el atacante puede manipular un bit interno relacionado con el motor de pila (Stack Engine) y forzar un comportamiento erróneo en el hilo objetivo, que es lo que se pretende con StackWarp. El resultado es una corrupción controlada del Stack Pointer, lo que permite alterar el flujo de ejecución dentro de una máquina virtual supuestamente protegida.

No se rompe el cifrado de memoria, pero sí la integridad del cálculo que se está haciendo, lo que en la práctica es igual o más grave si cabe por motivos obvios de seguridad. Se ha demostrado que esto permite desde extraer claves criptográficas hasta saltarse comprobaciones de seguridad o modificar la ejecución de procesos críticos dentro de la VM sin importar si hablamos de Zen 1 o Zen 5, con todas las arquitecturas que hay en medio de ellas.

Pero esto no termina aquí por desgracia. Es cierto que no es una vulnerabilidad explotable a gran escala, por suerte, pero sí un recordatorio de que el aislamiento total sigue dependiendo de supuestos muy frágiles a nivel de la microarquitectura como es el SMT. Lo mejor de todo esto es que los rojos se pusieron las pilas y, vista la vulnerabilidad de julio, está, o debería estar, parcialmente corregida en una gran cantidad de sistemas.

Tres opciones para solucionar total o parcialmente la vulnerabilidad, si no hay todavía respuesta

La solución pasa por donde tenía que pasar desde aquella fecha: microcódigo y firmware. AMD ya ha publicado mitigaciones que corrigen el comportamiento del Stack Engine, y ahora la responsabilidad recae en los fabricantes de servidores para integrar esas actualizaciones en BIOS y plataformas reales.

Como medida temporal, se recomienda a los administradores de sistemas el desactivar SMT por el tipo de vulnerabilidad y su naturaleza, lo que reduce la superficie de ataque, aunque a costa de rendimiento. No es elegante, pero es eficaz, y en estos casos, dado que todo es con VM, es más crítico estar seguro que tener Multi Thread en los núcleos del procesador.

StackWarp no es una vulnerabilidad grave para el usuario final y el gamer medio como somos nosotros, pero sí una señal clara para el sector y su infraestructura con el SMT en liza otra vez, la segunda en 6 meses. Al final, parece que Intel sí que hizo algo bien quitándoselo de en medio en todas las nuevas arquitecturas, aunque no al 100%, esto también hay que decirlo.