Hace poco se dio a conocer informacion sobre una vulnerabilidad que ponia en jaque a los servidores en la nube. La vulnerilidad permite tomar el control absoluto de la máquina física, siendo este escenario de pesadilla para los proveedores de infraestructura cloud.
Zapscape registrada bajo el identificador CVE-2026-64561, es una vulnerabilidad crítica en el hipervisor KVM de Linux que expone un riesgo que muchas plataformas asumen casi sin querer al habilitar la virtualización anidada. Esta brecha permite a un atacante con privilegios en el kernel de una máquina virtual (L1) ejecutar código con permisos root en el sistema anfitrión (L0), demoliendo el aislamiento de los entornos virtualizados.
Considerada como una amenaza de alto impacto, Zapscape no solo facilita el escape de la máquina virtual, sino que también abre una ruta de escalada de privilegios local para usuarios del anfitrión que posean permisos de escritura sobre el dispositivo /dev/kvm.
Aunque organizaciones como Red Hat han clasificado el fallo con un puntaje CVSS de 7.0 enfocándose en la inestabilidad y denegación de servicio, la prueba de concepto (PoC) pública demuestra un alcance mucho más destructivo: la creación de un archivo arbitrario directamente en la raíz del host.
El caos en la unidad de gestión de memoria
La forma en la que opera Zapscape se esconde en la unidad de gestión de memoria (MMU) de KVM y en cómo el hipervisor maneja las tablas de páginas cuando un invitado (L1) actúa como hipervisor para otro sub-invitado (L2). El problema radica en un error de ordenamiento lógico durante el manejo de fallos de página. En las rutas de código del kernel, la comprobación de una «raíz obsoleta» se ejecutaba antes de la función de recuperación de páginas, en lugar de hacerlo después.
Esta secuencia incorrecta desencadena un clásico escenario de uso de memoria liberada (use-after-free). Durante la recuperación, KVM puede eliminar la raíz que está utilizando y marcarla como inválida. Sin embargo, como la comprobación de estado ya se ejecutó, el sistema continúa construyendo mapeos bajo una raíz que ya no es válida. Curiosamente, este problema de ordenamiento existe en el código desde 2008, pero se volvió crítico y explotable a partir del lanzamiento del kernel de Linux 5.9 en julio de 2020, cuando se introdujo una directiva que el sistema simplemente dejó de cumplir.
Requisitos y limitaciones
Para que Zapscape sea explotable, el entorno debe cumplir con requisitos muy específicos. En primer lugar, la virtualización anidada debe estar activa en el módulo de KVM, una configuración que permite la arquitectura de tres niveles (L0, L1 y L2). El atacante necesita iniciar el asalto desde la capa L1, para lo cual requiere permisos root en dicha máquina virtual. A partir de ahí, el atacante manipula los modos de memoria mientras la actividad del sub-invitado L2 empuja al anfitrión L0 a iniciar la recuperación de páginas por cuotas, provocando la corrupción de la memoria.
A nivel de hardware, las condiciones varían según el fabricante. En sistemas AMD que utilizan tablas de páginas anidadas (SVM), la vulnerabilidad es más directa y no requiere características extra. Por el contrario, en procesadores Intel, el escenario exige que el invitado L1 tenga expuestas las capacidades de paseo de páginas EPT de cuatro y cinco niveles. Esto limita el vector de ataque en Intel a arquitecturas más recientes, específicamente desde la familia Ice Lake-SP en adelante.
Cabe destacar que, aunque la prueba de concepto pública ha logrado escapar hacia el anfitrión en entornos controlados, investigadores de seguridad han reportado que en ciertos núcleos recompilados el exploit simplemente colapsa la máquina virtual del atacante, actuando como una denegación de servicio en lugar de un escape completo.
Mitigación, parches y estrategias
La solución definitiva a Zapscape llegó a los repositorios de Linux el pasado mes de julio con un parche que corrige el orden de la validación. Este arreglo reubica la comprobación de la raíz obsoleta para que ocurra después de la asignación de páginas de la MMU, asegurando que el hipervisor no cree mapeos activos bajo una raíz eliminada. Estas correcciones ya se han implementado en las ramas estables del kernel y están siendo distribuidas masivamente por las diferentes distribuciones.
Para los administradores que no puedan actualizar de inmediato, existen mitigaciones temporales altamente efectivas. La acción prioritaria es deshabilitar la virtualización anidada en todos los servidores donde no sea estrictamente necesaria, pasando los parámetros nested=0 a los módulos kvm_amd o kvm_intel en los archivos de configuración de modprobe. Esta medida requiere recargar el módulo, lo que implica detener las máquinas virtuales activas.
Finalmente, si estas interesado en poder conocer mas al respecto puedes consultar los detalles en el siguiente enlace.
Continúar leyendo...