VidMessageStopRequestCompleteDirect = 0x000D | VID_MESSAGE_TYPE_FLAG_INTERCEPT, VidMessagePassthroughIntercept = 0x000C | VID_MESSAGE_TYPE_FLAG_INTERCEPT, VidMessageGuestControlForPageCopy = 0x000B, Message types corresponding to other monitored events. VidMessageRegister = 0x0006 | VID_MESSAGE_TYPE_FLAG_INTERCEPT, VidMessageMmio = 0x0005 | VID_MESSAGE_TYPE_FLAG_INTERCEPT, VidMessageExecuteInstruction = 0x0004 | VID_MESSAGE_TYPE_FLAG_INTERCEPT, VidMessageTripleFault = 0x0003 | VID_MESSAGE_TYPE_FLAG_INTERCEPT, VidMessageException = 0x0002 | VID_MESSAGE_TYPE_FLAG_INTERCEPT, Message types corresponding to generic hypervisor intercepts.
These are the possible VID notifications for 圆4: typedef enum _VID_MESSAGE_TYPE Most of the flows which end up in the worker process start with a VND notification. The VND allows clients to register and receive VID notifications generated by actions performed by the guest. The VID Notification Dispatcher (VND) is a crucial component of this communication. This interface is clear from the import table in VMWP. Since the worker process needs an interface to the VID, it uses a userspace library which has an interface to the driver, called vid.dll (as opposed to vid.sys). In addition, the VID also emulates MMIO (and ROMs). VID sends management commands to the hypervisor using hypercalls, for operations such as: This driver also connects the hypervisor with the Virtual Machine Management Services (VMMS). The worker process runs in the root partition and communicates with the hypervisor through the Virtualization Infrastructure Driver (vid.sys). First, let’s look at the general virtualization architecture: Let’s dig into the internals of the worker process, looking at some of its components and the interesting flows for different operations. Internals: classes, interfaces, responsibilities and the way it works. In this blog, I would like to talk a little bit about VMWP Oh, and you’ve got public symbols to work with. VMWP seems like a good place to look for vulnerabilities: it’s fairly easy to debug, it has a huge attack surface, and it implements complex drivers. Components like that are usually very complex, and complex things are hard to implement correctly… and that’s where you get into the picture. We need a component to implement emulated/non-emulated devices, and we strongly prefer to implement it in userspace rather than kernelspace. You may think of the VMWP as our “ QEMU”-style process. As we stated in the first blog post, here are a few examples of components that reside in VMWP: When running Hyper-V, there is one instance of VMWP.exe process for each of the virtual machines. One of the largest attack surfaces in our virtualization stack is implemented in the userspace of the root partition and resides in the Virtual Machine Worker Process (VMWP.exe). What is the Virtual Machine Worker Process? With that, it’s time we dig deeper into the internals of VMWP, and consider what other vulnerabilities might be there. In August, Joe Bialek gave an amazing talk at Black Hat, describing how he exploited another vulnerability in the IDE emulator, which resides in the Virtual Machine Worker Process (VMWP). In this blog they dig deep into the VSPs-VSCs communication via VMBus and describe an interesting guest-to-host vulnerability in vPCI VSP, which resides in the root partition’s kernel (vpcivsp.sys). We then published “ Fuzzing para-virtualized devices in Hyper-V”, which has been the focus of our friends at the Virtualization Security Team. Our first blog post, “ First Steps in Hyper-V Research”, describes the tools and setup for debugging the hypervisor and examines the interesting attack surfaces of the virtualization stack components. In the past year we invested a lot of time making Hyper-V research more accessible to everyone.
0 kommentar(er)
