Cuando confías en una máquina virtual, das por hecho que lo que ocurre dentro se queda dentro. Esa barrera es precisamente lo que pone en jaque Zapscape, una vulnerabilidad crítica descubierta en KVM, el hipervisor incluido en el kernel de Linux, que permite a un atacante con privilegios dentro de una máquina virtual escapar de ella y tomar el control del servidor físico que la aloja. Registrada bajo el identificador CVE-2026-64561, esta brecha de seguridad afecta a un escenario muy concreto pero extendido en la nube: el de la virtualización anidada, esa técnica que permite ejecutar una máquina virtual dentro de otra máquina virtual.
El problema no es menor. Zapscape no se limita a bloquear o desestabilizar el sistema, sino que en su forma más grave permite que un atacante que ya controla el kernel de una máquina virtual de primer nivel, conocida como L1, ejecute código con permisos de administrador en el anfitrión físico, denominado L0. Dicho de otro modo, el aislamiento que se supone debe separar a los distintos inquilinos de un servidor compartido queda completamente anulado. Además del escape entre entornos virtualizados, la vulnerabilidad también abre una vía de escalada de privilegios local para cualquier usuario del propio host que tenga permisos de escritura sobre el dispositivo dev kvm, ampliando así su superficie de riesgo.
Organizaciones como Red Hat han valorado el fallo con una puntuación CVSS de 7.0, centrada sobre todo en el riesgo de inestabilidad y denegación de servicio. Sin embargo, la prueba de concepto publicada de forma pública demuestra un alcance más severo, ya que consigue crear un archivo arbitrario directamente en la raíz del sistema anfitrión, una evidencia clara de que el compromiso puede ir mucho más allá de un simple cuelgue.
El origen de Zapscape está en la unidad de gestión de memoria de KVM, concretamente en la forma en que el hipervisor administra las tablas de páginas cuando una máquina virtual L1 actúa a su vez como hipervisor de una segunda máquina virtual L2. El fallo es, en esencia, un problema de orden de ejecución dentro del código del kernel. Durante el manejo de fallos de página, la comprobación de si una raíz de memoria estaba obsoleta se realizaba antes de que se ejecutara la función encargada de recuperar páginas, cuando debía ocurrir justo después.
Esa secuencia invertida genera un caso clásico de uso de memoria después de haber sido liberada, un tipo de error conocido como use-after-free. Durante el proceso de recuperación, KVM puede eliminar la raíz de memoria que estaba utilizando y marcarla como no válida. El problema es que, como la comprobación de estado ya se había ejecutado antes con la información antigua, el sistema sigue construyendo mapeos de memoria apoyándose en una raíz que ya no existe de forma legítima. Lo llamativo es que este error de ordenamiento está presente en el código desde 2008, pero no se convirtió en explotable hasta la llegada del kernel de Linux 5.9 en julio de 2020, momento en el que se introdujo una directiva de comportamiento que el sistema, en la práctica, dejó de respetar.
Para que esta vulnerabilidad de KVM pueda aprovecharse, el entorno debe cumplir una serie de condiciones bastante específicas, lo que limita su impacto a determinados escenarios de infraestructura. La primera y más importante es que la virtualización anidada esté activada en el módulo KVM del servidor, ya que sin esa configuración de tres niveles, con L0, L1 y L2, el vector de ataque simplemente no existe. El atacante, además, necesita partir de la capa L1 con permisos de administrador dentro de esa máquina virtual, y desde ahí manipular los modos de memoria mientras la actividad de la máquina virtual L2 obliga al anfitrión L0 a iniciar procesos de recuperación de páginas, lo que termina provocando la corrupción de memoria.
Las condiciones de hardware también influyen en la facilidad de explotación. En procesadores AMD que emplean tablas de páginas anidadas mediante SVM, la vulnerabilidad resulta más directa de aprovechar y no exige requisitos adicionales. En el caso de Intel, en cambio, es necesario que la máquina virtual L1 tenga expuestas las capacidades de paseo de páginas EPT de cuatro y cinco niveles, lo que reduce el abanico de procesadores afectados a arquitecturas relativamente recientes, en concreto desde la familia Ice Lake-SP en adelante. Vale la pena señalar que, según han reportado investigadores de seguridad, en algunos núcleos recompilados el intento de explotación no llega a completar el escape y en su lugar provoca el colapso de la propia máquina virtual atacante, funcionando más como una denegación de servicio que como una fuga real hacia el host.
La solución definitiva a Zapscape ya está disponible. El parche que corrige el orden incorrecto de validación llegó a los repositorios del kernel de Linux el pasado mes de julio, y reubica la comprobación de la raíz obsoleta para que se ejecute después de la asignación de páginas de la unidad de gestión de memoria, evitando así que el hipervisor construya mapeos activos sobre una raíz que ya ha sido eliminada. Esta corrección ya forma parte de las ramas estables del kernel y se está distribuyendo progresivamente a través de las principales distribuciones Linux.
Para los administradores de sistemas que no puedan aplicar la actualización de inmediato, existe una mitigación temporal razonablemente eficaz: desactivar la virtualización anidada en todos los servidores donde no resulte estrictamente necesaria. Esto se consigue pasando el parámetro nested=0 a los módulos kvm_amd o kvm_intel en la configuración de modprobe, aunque conviene tener en cuenta que aplicar este cambio obliga a recargar el módulo correspondiente, lo que a su vez implica detener las máquinas virtuales que estén activas en ese momento.
Casos como Zapscape recuerdan que la virtualización, pese a llevar más de dos décadas como pilar de la informática moderna, sigue apoyándose en piezas de software enormemente complejas donde un simple error de orden en unas pocas líneas de código puede tardar más de una década en manifestarse como un riesgo real. La pregunta que queda flotando no es solo cuántas vulnerabilidades similares siguen agazapadas en capas de software que damos por confiables, sino hasta qué punto la comodidad de anidar entornos virtuales de forma casi automática compensa el riesgo que añade a la superficie de ataque de cualquier infraestructura en la nube.
Fuente: Desde linux
Añadir comentario
Comentarios