There is quite a bit of documentation on bare metal or Type 1 hypervisors, including my own book, VMware vSphereTM and Virtual Infrastructure Security: Securing the Virtual Environment, but there is not much material on the proper security of hosted environments, or Type 2 hypervisors, such as Microsoft Virtual Server, VMware Workstation, Fusion, Player, or Server as well as Qemu, Virtuozzo, or OpenVZ.
There is an interesting discussion about this on the VMware Communities on just this subject. It is interesting given the vulnerability being discussed is CVE-2009-1244 (or VMware’s ID VMSA-2009-0006) which relate to Guest Operating System driver vulnerabilities in hosted environment. It relates specifically to paravirtualized video drivers allowing the possibility of code to run within the host from within the Guest OS. In other words, escaping the VM.There have been two known “escape the VM” vulnerabilities within hosted environments. The first was a directory traversal attack against the VMware HGFS driver used within VMware Workstation. This attack NEVER affected Type 1 hypervisors. The other is the previously mentioned driver issue. There have been other attacks against drivers that could crash a VM but never escape the VM. These escapes however only work within a hosted environments. Does this mean we should be unconcerned about escapes occurring within Type 1 hypervisors? Not at all.
Virtualization security is built upon the tripod of Management, Network, and Hypervisor security. However, with Type 2 hypervisors all three of these are rolled into the single operating system hosting the Type 2 hypervisor.
So what is the security of Type 2 hypervisors?
Type 2 hypervisor security is directly related to the security of the hosted system. If an attacker can break the hosted system then all that is virtualized within it now becomes known to the attacker. Is this not the same for Type 1 hypervisors? Yes and no. But that is another post. Type 2 hypervisors bridge the network through the host operating system before it reaches the virtual machine. Which implies that the host operating system firewall and countermeasures also impact virtual machine network traffic.
Well that sounds great! How can I get some, centralized firewalls?
Because all the traffic must go through the host by normal means, that implies that traffic could be intercepted by the host as well. Remember Type 2 hypervisors are as secure as the hosts upon which they run. An attack could come in through the network used for VMs, but target the host.
On the VMware Communities there was an interesting thread about how to protect the host OS used by the hypervisor entitled Would qemu or openvz perhaps be more secure than vmware. This thread is about two specific and somewhat different issues. The first is some how alleviating VM escapes by layering virtualization techniques. The second issue is limiting the network attack surface so that the host OS is not involved with the network. This post goes to show that there are ways to secure things within a Type 2 hypervisor but also that there are other risks presented when you change the basic networking.
The premise of this post is that the only network allowed would be through a USB device connected directly to the VM. This would alleviate all network based attacks against the host OS and leave only VM escapes. This is an ingenious approach but does have some minor risk. In order for the USB device to be put into passthru mode and attached to the VM it must traverse a device driver within the host OS. Is this a high risk? Not at all.
What this does not address is any network based attacks that will now target the guest OS. Nor escapes of the VM. To do this the suggestion was to run an OS within qemu within the guest OS within the host OS. This layering approach does not really help all that much as the network attack point will be the guest OS not the OS within qemu.
It is an ingenious design, however, to remove the Host OS from the network security equation within Type 2 hypervisors. This solution only works with passthru networking adpaters such as USB and eventually SR-IOV. Type 2 hypervisors can be network secured. But escape the VMs still are an issue. So ensure interactions between the VMs and hosts are limited, isolation settings are properly set, and pay attention to CVEs related to virtualization.