Another Road Leads to the Host: From a Message to VM Escape on Nvidia vGPU

The presentation discusses the exploitation of vulnerabilities in the NVIDIA vGPU Manager and provides insights into the process of reverse engineering and patching the guest kernel driver.

• The main manager process is loaded on address four with 5 0's, making it easier to exploit vulnerabilities
• The vGPU Manager does not enable ASLR, making it easier to bypass
• The presentation focuses on the message handler function and the process of generating dossier files through EDA
• The presentation provides insights into the process of reverse engineering and patching the guest kernel driver
• The presentation discusses the use of a GDP script to create handles and randomly fund them

The presenter discusses the process of locating the code where the vRPC body is on the left side of the assignment and operating on a keyword or void as risk. They locate three places but only one meets their requirements. They use a GDP script to fuse it and finally make it return successfully. They also discuss the use of randomization during the funding process.

NVIDIA has a huge market share in the area of vGPU. Starting from supporting artificial intelligence, deep learning, data science to cloud gaming, the vGPU is getting more and more perceived to the general public. The vGPU can bring a new attack surface to the cloud infrastructures.Compared to well-analyzed hypervisors, there is still not much research on the security of vGPU and its components. The problem that researchers will face is not only the lack of information but also that all the components of NVIDIA vGPU are closed-source, with no symbols and obfuscated function names. Regardless of the hypervisor, vGPU has a component called nvidia-vgpu-mgr, running independently on the host. Through a detailed study of it, we have figured out how the guest machine is communicating with the vGPU manager. The guest kernel driver in the guest virtual machine communicates with the host through a mechanism called "vRPC message". This message is first processed by nvidia-vgpu-mgr, reorganized, and then sent via ioctl to the host kernel driver, for further processing. We've developed several fuzz methods to test if its handler is secure. The security of its kernel drivers is also tested through fuzzing. So far, we have found multiple vulnerabilities in its vRPC handler. Three of them are OOB write, one of them is OOB read/write, and the last one is an information leak. We have also found a vulnerability in the kernel that can be triggered directly from the guest machine, resulting in arbitrary kernel address writing.By using these vulnerabilities, regardless of the hypervisor, an attacker could exploit the nvidia-vgpu-mgr from the guest machine and get root access on the host machine.