VM Escape

[Kah2008]

I am continually questioned about VM escape. From the research I have done, it has not happened yet in ESX or ESXi. I know there were some vulnerabilities with workstation and server, but assuming hosts and guest are patched and the Security Hardening guidelines are followed, what are the real possibilities of it happening with ESXi4.1?

I was also shown this link today- http://www.blackhat.com/presentations/bh-usa-09/KORTCHINSKY/BHUSA09-Kortchinsky-Cloudburst-SLIDES.pd... - is this a possibility for vm escape?

[Texiwill]

Hello,

All the current VM Escapes will not 'escape a VM' within ESX or ESXi. They will however, possibly crash a VM, which is in effect a DoS attack. However, if you have properly patched VMware Tools, then that is not possible either.... Most of the VM escapes either look at the vCPU cache to see if they can find anything about their neighbors or attack the paravirtualized drivers. THe most common one attacked is the svga driver for windows. In many cases if you do not need a paravirtualized driver you should not install them.

Be aware that you often need these drivers to get better performance out of the VM, maintain heartbeat, etc.

The architecture of ESX/ESXi is pretty darn good and designed to prevent such attacks, will it be possible, maybe some day, but not today.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition (do out mid January)

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[Cryptoad]

This is answer is incorrect and misleading.

The attacks allowing a VM escape do not rely on drivers (that run in the kernel context of the guest) but on the virtualized hardware (that runs in the context of the vmx process on the host), or on some hypervised-cpu issues as stated (on the host again).

Having or not VMware tools and their specific drivers in the Guest does not change the presence of potential vulnerability in the vmx process on the host.

So no, the "windows drivers" are not the most common attack. No, not installing a driver will not prevent you from being attacked if the vulnerability is present in your VMware version. Yes, ESX 3 and 4RC were vulnerable to the CLOUDBURST attack (please check CVE-2009-1244 "Host code execution vulnerability from a guest operating system"  http://lists.vmware.com/pipermail/security-announce/2009/000055.html).

[Texiwill]

Hello,

Not at all misleading. The issue is:

> A critical vulnerability in the virtual machine display function
> might allow a guest operating system to run code on the host

The display of the VM via the VMware Workstation, Player, Fusion, or Server display is quite a bit different than the display of a VM's Guest OS user interface when using VMware ESX or ESXi. In essence with the hosted products you are running the code within the host to do the display functions. On ESX, you are not running the display functions on the host, but instead using VNC, web interface, or the vSphere CLient. Could the same attack work in this case? Not sure, but I seriously doubt it given how the 'arbitrary code' would have to travel from the ESX host to the display tool.

Since VMware uses the same or similar code base for each of their hypervisor products, a fix to one would translate to being part of a fix to another and a preventative for ESX/ESXi.

Also, this fix was to 'VMware Tools', the Firmware loaded by the VM. Since VMware Tools is the same across all systems a change to tools for Workstation applies to all the other products as well. The same firmware is also used across all products.

While the fixes often apply to both (hosted and ESX/ESXi) manipulating those issues within ESX/ESXi is quite difficult and usually impossible given how the Operating Systems involved actually work. For display functions to allow code to run on a 'host' they must be running on the host involved. But with ESX/ESXi they are not running on the host involved, but within one of the possible clients. Could you escape the VM to a client via the Virtual Infrastructor Client? Perhaps... but the attack would then have to break not the host but the actual client running the VIrtual Infrastructure Client.

There are far easier ways to break the client running one of the ESX/ESXi management tools.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition (do out mid January)

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[Cryptoad]

Hello,

There is here a major misunderstanding of what the discussed vulnerability was. Let me clarify some points your raised:

>  Could the same attack work in this case? Not sure, but I seriously doubt it given how the 'arbitrary code' would have to travel from the ESX host to the display tool.

Yes I am sure, I wrote the exploit for ESX 4.0 RC.

>  Also, this fix was to 'VMware Tools', the Firmware loaded by the VM.

No. The vulnerable code is located inside the VMX binary, running on the Host, which is not updatable by the tools (it would be a major security flaw), and has nothing to do with the 'firmware' of the virtualized graphic card (or any 'firmware'). As a side note, firmware for the virtualized hardware components are located inside the vmware-vmx binary as resources and are not updatable by the tools either.

> But with ESX/ESXi they are not running on the host involved, but within one of the possible clients.

In our case, this is incorrect. We are not talking about rendering graphics on a screen/terminal/remote session/whatever, but sending graphic processing commands to a hardware device. If you are doing an insb/outsb (http://en.wikipedia.org/wiki/Memory-mapped_I/O) to the correct I/O region of the VMware SVGA II card (even if the driver from the tools is not installed), it will be processed by the hardware virtualization layer located inside vmware-vmx, once again on the host. Whatever the rendering backend (VNC for example) is, and this doesn't change with ESX. This is true for most of the virtualized hardware (think virtualized network card, virtualized SCSI card, etc.).

You can have a look at the architecture design of the virtual video card in a VMware presentation done at Usenix:

http://www.usenix.org/event/wiov08/tech/full_papers/dowty/dowty.pdf

"Figure 2" will give a clear representation of what is running on the Host and on the Guest. As you can see, only a small portion of the graphic processing is located in the Guest (processing != rendering). And 2D or 3D work the same (and yes, the 3D processing code was present in ESX 4 last time I checked).