VMScape Spectre-BTI: la fuga de datos de invitado a host que inquieta a la nube
Un equipo de ETH Zurich ha desvelado VMScape (Spectre-BTI), un ataque de ejecución especulativa capaz de que una máquina virtual controlada por un atacante cruce el aislamiento y extraiga datos del sistema anfitrión. Catalogado como CVE-2025-40300, se apoya en debilidades del predictor de saltos y afecta a procesadores actuales de AMD e Intel.
La novedad es que funciona sobre hipervisores sin modificar en configuraciones por defecto de nube, apuntando al stack KVM/QEMU. En sus pruebas, los investigadores lograron filtrar memoria del proceso QEMU a 32 B/s y recuperar secretos sensibles —incluidas claves criptográficas— en unos 18 minutos (≈1.092 s).
VMScape explota brechas en la predicción de saltos
El ataque se sostiene en un aislamiento incompleto de la Unidad de Predicción de Saltos (BPU). Las CPU modernas aceleran el rendimiento anticipando saltos, pero las barreras de hardware como eIBRS y AutoIBRS son demasiado gruesas en entornos virtualizados y no distinguen finamente entre cuatro dominios clave: HU (usuario del host), HS (supervisor del host), GU (usuario del invitado) y GS (supervisor del invitado).
Esta falta de granularidad abre la puerta a la interferencia entre dominios. Según el equipo, incluso con mejoras recientes en procesadores de última generación, el aislamiento entre GU y HU no queda garantizado si no se refuerza con medidas adicionales, lo que deja un resquicio aprovechable por un invitado malicioso.
Cadena de ataque y técnica de exfiltración
Los investigadores describen un primitivo de ataque de virtualización para Spectre-BTI denominado vBTI GU→HU: un proceso no privilegiado dentro de la VM entrena el predictor de saltos y consigue influir en la especulación de un proceso de usuario en el host (el propio QEMU). Así, tras un VMEXIT, el anfitrión puede acabar ejecutando de forma especulativa un «disclosure gadget» ya presente en su código.
La exfiltración se realiza byte a byte con el canal lateral de caché FLUSH+RELOAD. Para hacerlo viable, el invitado prepara memoria compartida asignada también en el espacio de QEMU, y recurre a patrones de acceso muy precisos; en algunos escenarios aprovecha MMIO para facilitar control de registros y aumentar la fiabilidad del filtrado.
Un reto clave es ampliar la «ventana de especulación». El equipo logró retrasar la resolución del salto correcto mediante conjuntos de desalojo contra la LLC no inclusiva de AMD Zen 4 y Zen 5, alargando ese intervalo crítico y sosteniendo una tasa de fuga de 32 B/s sobre el proceso QEMU del host.
La explotación es de extremo a extremo: además de la fase de entrenamiento y activación tras el VMEXIT, incluye técnicas para sortear ASLR y localizar los gadgets de divulgación y regiones objetivo, completando todo el recorrido en plazos observados en torno a los 18 minutos.
Alcance y plataformas afectadas
VMScape impacta a una amplia franja de CPUs modernas: AMD Zen 1 a Zen 5 y la familia Intel Coffee Lake. El vector probado se centra en el ecosistema de virtualización KVM/QEMU, muy extendido en nubes públicas y privadas, por lo que el riesgo en entornos multiinquilino no es baladí.
En estas condiciones, una VM con intención maliciosa puede interferir con el estado del predictor del host y forzar especulación hacia gadgets ya existentes, sin necesidad de modificar el hipervisor, un detalle que eleva la criticidad operacional de la vulnerabilidad.
Mitigaciones disponibles y coste en rendimiento
Tras la divulgación responsable, los mantenedores del kernel de Linux publicaron parches que introducen una barrera de predicción de saltos: IBPB en cada VMEXIT justo antes de regresar al espacio de usuario del hipervisor (QEMU). Esta limpieza del estado envenenado de la BPU rompe la primitiva de ataque.
Para reducir el impacto, el kernel aplica el vaciamiento de predictores de forma condicionada, activándolo solo cuando es necesario. En cargas típicas el coste medido ronda el ≈1%, aunque en escenarios intensivos de E/S puede elevarse de forma notable, con picos reportados de hasta el 51% según pruebas concretas.
Los parches están disponibles en Linux 6.8 y posteriores, y se recomienda actualizar QEMU/KVM a versiones que respeten la nueva secuencia de transición. Además, conviene revisar políticas de despliegue para asegurar que IBPB se emite sistemáticamente en las salidas de VM.
Cronología y respuesta del ecosistema
El equipo notificó el fallo a los PSIRT de AMD e Intel el 7 de junio de 2025, bajo embargo coordinado hasta el 11 de septiembre de 2025. En ese intervalo se trabajó con la comunidad para preparar mitigaciones y facilitar su adopción sin cambios intrusivos en los hipervisores.
Con el levantamiento del embargo, los proveedores de nube y administradores on‑premise han sido instados a aplicar las actualizaciones sin demora. En instalaciones donde la compartición de hardware entre clientes es la norma, reducir el tiempo de exposición es, sencillamente, crítico.
Recomendaciones prácticas para equipos de seguridad
Prioriza la actualización del kernel a ramas con IBPB-before-exit-to-userspace y verifica que el hipervisor en producción hereda la mitigación. Donde no sea posible actualizar de inmediato, evalúa controles compensatorios (aislamiento de cargas sensibles, afinidad de CPU, reducción de co‑ubicación).
Refuerza la observabilidad: monitoriza VMEXIT anómalos, tasas de fallos de caché y patrones inusuales en QEMU. A efectos de riesgo, trata claves de cifrado y otros secretos de infraestructura como datos de alto valor potencialmente expuestos en hosts compartidos.
En auditorías y modelado de amenazas, asume que las defensas por nivel de privilegio (eIBRS/AutoIBRS) pueden resultar insuficientes frente a ataques de espectro cruzado entre huésped y anfitrión, y documenta políticas de rotación de material criptográfico acorde al nuevo escenario.
La aparición de VMScape confirma que el superface de ataque de la ejecución especulativa sigue vigente en la virtualización: un invitado puede forzar especulación en el host y filtrar memoria con 32 B/s, pero las mitigaciones basadas en IBPB en VMEXIT, ya presentes en Linux moderno, permiten atajar el problema con impacto acotado en la mayoría de cargas.