Los investigadores del equipo de Google Project Zero dieron a conocer hace pocos dias en una publicación de blog que han identificado una vulnerabilidad (CVE-2021-29657) en el hipervisor KVM (un hipervisor de código abierto basado en Linux que admite la virtualización acelerada por hardware en x86, ARM, PowerPC y S/390) que permite evitar el aislamiento del sistema invitado y ejecutar su código en el lado del entorno de acogida.

En la publicación se menciona que el problema se manifiesta desde el kernel de Linux 5.10-rc1 a v5.12-rc6, es decir, cubre solo los núcleos 5.10 y 5.11 (la mayoría de las ramas estables de distribuciones no se vieron afectadas por el problema). El problema está presente en el mecanismo nested_svm_vmrun, implementado usando la extensión AMD SVM (Secure Virtual Machine) y permitiendo el lanzamiento anidado de sistemas invitados.

En esta publicación de blog, describo una vulnerabilidad en el código específico de AMD de KVM y discuto cómo este error puede convertirse en un escape completo de la máquina virtual. Hasta donde yo sé, esta es la primera redacción pública de una ruptura de huésped a host de KVM que no depende de errores en los componentes del espacio de usuario como QEMU.

Al error discutido se le asignó CVE-2021-29657, afecta a las versiones del kernel v5.10-rc1 a v5.12-rc6 y fue parcheado a fines de marzo de 2021 . Como el error solo se volvió explotable en v5.10 y se descubrió aproximadamente 5 meses después, la mayoría de las implementaciones de KVM en el mundo real no deberían verse afectadas. Sigo pensando que el problema es un estudio de caso interesante en el trabajo requerido para construir un escape estable de huésped a host contra KVM y espero que este artículo pueda fortalecer el caso de que los compromisos del hipervisor no son solo problemas teóricos.

Los investigadores mencionan que para la correcta implementación de esta funcionalidad, el hipervisor debe interceptar todas las instrucciones SVM ejecutadas en los sistemas invitados, emular su comportamiento y sincronizar el estado con el hardware, lo cual es una tarea bastante complicada.

Después de analizar la implementación de KVM propuesta, los investigadores encontraron un error lógico que permite que el contenido del MSR (Registro específico del modelo) del host sea ​​influenciado desde el sistema invitado, que puede usarse para ejecutar código en el nivel del host.

En particular, la ejecución de una operación VMRUN desde un sistema invitado del segundo nivel de anidamiento (L2 lanzado desde otro invitado) conduce a una segunda llamada a nested_svm_vmrun y daña la estructura svm-> nested.hsave, que se superpone con datos de vmcb del sistema invitado L2.

Como resultado, surge una situación en la que en el nivel de invitado L2 es posible liberar memoria en la estructura svm-> nested.msrpm, que almacena el bit MSR, a pesar de que continúa utilizándose, y acceder al MSR del entorno de acogida.

Esto significa, por ejemplo, que la memoria de un huésped se puede inspeccionar volcando la memoria asignada de su proceso de espacio de usuario o que los límites de recursos para el tiempo de CPU y la memoria se pueden aplicar fácilmente. 

Además, KVM puede descargar la mayor parte del trabajo relacionado con la emulación de dispositivos al componente del espacio de usuario.

El problema está presente en el código utilizado en los sistemas con procesadores AMD (módulo kvm-amd.ko) y no aparece en los procesadores Intel.

 Fuera de un par de dispositivos sensibles al rendimiento relacionados con el manejo de interrupciones, todo el código complejo de bajo nivel para proporcionar acceso a disco virtual, red o GPU se puede implementar en el espacio de usuario.  

Los investigadores además de describir el problema tambien han preparado un prototipo funcional de un exploit que permite ejecutar un shell root desde un entorno invitado en un entorno host en un sistema con un procesador AMD Epyc 7351P y un kernel Linux 5.10.

Se observa que esta es la primera vulnerabilidad de invitado a host en el hipervisor KVM en sí, no relacionada con errores en los componentes del espacio de usuario como QEMU. La corrección se aceptó en el kernel a finales de marzo.

Finalmente si estás interesado en conocer más al respecto sobre la nota, puedes consultar los detalles en el siguiente enlace.