Researchers from the Google Project Zero team disclosed a few days ago in a blog post that have identified a vulnerability (CVE-2021-29657) in the KVM hypervisor (an open source Linux-based hypervisor that supports hardware-accelerated virtualization on x86, ARM, PowerPC, and S / 390) that allows you to avoid isolation of the guest system and run your code on the host environment side.
The post mentions that the problem manifests from Linux kernel 5.10-rc1 to v5.12-rc6, it decir, covers only kernels 5.10 and 5.11 (Most of the stable branches of distributions were not affected by the problem.) The problem is present in the nested_svm_vmrun mechanism, implemented using the AMD SVM (Secure Virtual Machine) extension and allowing nested launch of guest systems.
In this blog post, I describe a vulnerability in the AMD-specific KVM code and discuss how this bug can turn into a complete virtual machine escape. As far as I know, this is the first public write-up of a KVM guest-to-host breakout that doesn't rely on bugs in user-space components like QEMU.
The bug discussed was assigned CVE-2021-29657, affects kernel versions v5.10-rc1 to v5.12-rc6, and was patched in late March 2021. As the bug only became exploitable in v5.10 and was discovered about 5 months later, most real-world KVM deployments should not be affected. I still think that the problem is an interesting case study in the work required to build a stable guest-to-host escape against KVM and I hope this article can make the case that hypervisor compromises are not just theoretical problems.
The researchers mention that for the correct implementation of this functionality, the hypervisor must intercept all SVM instructions run on guest systems, emulate its behavior and synchronize the state with the hardware, which is quite a difficult task.
After analyzing the proposed KVM implementation, the researcherss encountered a logical error that allows the content of the MSR (Model-specific registration) of the host be influenced from the guest system, which can be used to execute code at the host level.
In particular, running a VMRUN operation from a second nested level guest (L2 launched from another guest) leads to a second call to nested_svm_vmrun and corrupts the svm-> nested.hsave structure, which is overlaid with data from vmcb from the L2 guest system.
As a result, a situation arises where at the L2 guest level it is possible to free memory in the svm-> nested.msrpm structure, which stores the MSR bit, even though it continues to be used, and access the MSR of the host environment. .
This means, for example, that a guest's memory can be inspected by dumping the allocated memory of its user space process or that resource limits for CPU time and memory can be easily enforced.
In addition, KVM can offload most of the work related to device emulation to the user space component.
The problem is present in the code used on systems with AMD processors (kvm-amd.ko module) and does not appear on Intel processors.
Outside of a couple of performance-sensitive devices dealing with interrupt handling, all the complex low-level code for providing virtual disk, network, or GPU access can be deployed in user space.
The researchers in addition to describing the problem They have also prepared a working prototype of an exploit which allows running a root shell from a guest environment in a host environment on a system with an AMD Epyc 7351P processor and a Linux 5.10 kernel.
It is observed that this is the first guest-to-host vulnerability in the KVM hypervisor itself, not related to bugs in user space components like QEMU. The fix was accepted in the kernel at the end of March.
Finally if you are interested in knowing more about it about the note, you can check the details In the following link.