Can a virtual machine (VM) "hack" another VM running on the same physical machine?

Solution 1:

Of course it is possible to exploit another VM running on the same hardware, given a working exploit. Additionally, one can exist. Your question cites some recent work showing one. I'm not going to share any specific exploits or PoC here, but I'll gladly say how they can be made.

The exploits that are used in this context are naturally different from ones that function when you're running on the same machine you are trying to exploit a service on, and they tend to be quite a bit harder due to the increased isolation. However, some general approaches that can be used to accomplish such an exploit include:

• Attack the hypervisor. If you can get a sufficiently privileged shell on the hypervisor given a VM, you can gain control over any VM on the system. The way to approach this is to look for data flows that exist from the VM into the hypervisor, and are highly hypervisor-dependant; things like paravirtualized drivers, clipboard sharing, display output, and network traffic tend to create this type of channel. For instance, a malicious call to a paravirtualized network device might lead to arbitrary code execution in the hypervisor context responsible for passing that traffic to the physical NIC driver.
• Attack the hardware on the host. Many devices allow for firmware updates, and if it happens to be possible to access the mechanism for that from a VM, you could upload new firmware that favours your intentions. For instance, if you are permitted to update the firmware on the NIC, you could cause it to duplicate traffic bound for one MAC address (the victim's), but with another destination MAC address (yours). For this reason many hypervisors filter such commands where possible; ESXi filters CPU microcode updates when they originate from a VM.
• Attack the host's architecture. The attack you cited, essentially yet another timing-based key disclosure attack, does this: it exploits the caching mechanism's impact on operation timing to discern the data being used by the victim VM in its operations. At the core of virtualization is the sharing of components; where a component is shared, the possibility of a side channel exists. To the extent that another VM on the same host is able to influence the behaviour of the hardware while running in the victim VM's context, the victim VM is controlled by the attacker. The referenced attack makes use of the VM's ability to control the behaviour of the CPU cache (essentially shared universal state) so that the victim's memory access times more accurately reveal the data it is accessing; wherever shared global state exists, the possibility of a disclosure exists also. To step into the hypothetical to give examples, imagine an attack which massages ESXi's VMFS and makes parts of virtual volumes reference the same physical disk addresses, or an attack which makes a memory ballooning system believe some memory can be shared when in fact it should be private (this is very similar to how use-after-free or double-allocation exploits work). Consider a hypothetical CPU MSR (model-specific register) which the hypervisor ignores but allows access to; this could be used to pass data between VMs, breaking the isolation the hypervisor is supposed to provide. Consider also the possibility that compression is used so that duplicate components of virtual disks are stored only once - a (very difficult) side channel might exist in some configurations where an attacker can discern the contents of other virtual disks by writing to its own and observing what the hypervisor does. Of course a hypervisor is supposed to guard against this and the hypothetical examples would be critical security bugs, but sometimes these things slip through.
• Attack the other VM directly. If you have a proximal host to the victim VM, you may be able to take advantage of relaxed access control or intentional inter-VM communication depending on how the host is configured and what assumptions are made when deploying access control. This is only slightly relevant, but it does bear mention.

Specific attacks will arise and be patched as time goes on, so it isn't ever valid to classify some particular mechanism as being exploitable, exploitable only in lab conditions, or unexploitable. As you can see, the attacks tend to be involved and difficult, but which ones are feasible at a particular time is something that changes rapidly, and you need to be prepared.

That said, the vectors I've mentioned above (with the possible exception of the last one in certain cases of it) simply don't exist in bare-metal environments. So yes, given that security is about protecting against the exploits you don't know about and that aren't in the wild as well as the ones which have been publicly disclosed, you may gain a little security by running in bare metal or at least in an environment where the hypervisor doesn't host VMs for all and sundry.

In general, an effective strategy for secure application programming would be to assume that a computer has other processes running on it that might be attacker-controlled or malicious and use exploit-aware programming techniques, even if you think you are otherwise assuring no such process exists in your VM. However, particularly with the first two categories, remember that he who touches the hardware first wins.

Solution 2:

In theory, no. The whole point of the hypervisor is to isolate virtual machines from each other.

In practice, there have been (and could be in the future) security bugs in various hypervisors which could allow one virtual machine to affect either the hypervisor or other virtual machines on the same host. Security measures such as sVirt (for KVM/QEMU) are intended to solve this problem.

Solution 3:

Edit: I thought this topic was done with months ago, but it has just been revived and now OP is asking for more 'real facts, quoted studies,' etc., so I figured what the heck.

Exploits of this nature are:

1. Rare
2. Sensitive in nature and therefore not shared openly, and when they are, the exploits would be patched by the vendor before anyone on this site ever knew about them
3. Complicated and will vary by vendor

We can't say it's impossible to hack a hypervisor and gain access to other VMs. Nor can we quantify how much risk there is, except for that experience shows us that it's pretty low, considering that you will not find many stories of attacks that utilized hypervisor exploits.

Here's a sort-of interesting article to the contrary that suggests that more than a few hypervisor-based attacks have been carried out.

However, with technology depending on hypervisors now more than ever, such exploits would be patched and guarded against with more urgency than almost any other type of exploit.

Here is an excerpt from the IBM X-Force 2010 Mid-Year Trend and Risk Report:

(Please open this image in a new tab to view it full-size.)

Notice the measured percentage of "Escape to hypervisor" vulnerabilities, which sounds pretty scary to me. Naturally you'd want to read the rest of the report as there is a lot more data in it to back up the claims.

Here is a story about a possible exploit carried out on the Playstation 3 hypervisor, which is amusing. Maybe not as impactful to your business, unless your business is Sony, in which case it's extremely impactful.

Here is a wonderful article from Eric Horschman of VMware, in which he kind of comes off to me sounding like a teenager going full anti-Micro$oft, but it's still a good article. In this article, you'll find tidbits such as this:

The residents at Microsoft’s glass house had some other stones to toss our way. Microsoft pointed to CVE-2009-1244 as an example of a guest breakout vulnerability in ESX and ESXi. A guest breakout exploit is serious business, but, once again, Microsoft is misrepresenting the facts. VMware responded quickly to patch that vulnerability in our products, and ESX was much less affected than Microsoft would lead you to believe:

Quibbling amongst competitors. But probably the most lucid thing he says in the entire article is this:

The truth is, vulnerabilities and exploits will never completely go away for any enterprise software.

Solution 4:

The ever quotable Theo de Raddt of the OpenBSD project:

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

A bit inflammatory but his point is well taken. In theory virtualization is supposed to provide complete isolation between the virtual machines and their host. In practice there are occasional security vulnerabilities that allow advanced attackers to circumnavigate these protections and gain access to other virtual machines or even worse their host (see An Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments). As Ryan Ries mentions these kinds of vulnerabilities are pretty rare (which doesn't mean they aren't there) and often not disclosed by vendors but they do exist.

If you are concerned about the potential for these kinds of attacks (and I think to some degree you should be) I recommend that you do not mix security zones on a single virtual host or virtual host cluster. For example - you would have a dedicated two host virtual host cluster for DMZ virtual machines, a dedicated cluster for middleware and a dedicated cluster for protected assets. This way in the event that a vulnerability is exploited in such a way that allows an attacker to subvert other virtual machines or worse the hypervisor itself your security model is still intact.