VM Escape Possible on ESXi?

[TheVMinator]

I've read of a successful VM Escape on VMware Workstation - and that ESXi had a patch released in response to it:

https://threatpost.com/vm-escape-earns-hackers-105k-at-pwn2own/124397/

However, are there any documented sucessful VM Escape attacks on ESXi as opposed to workstation?   There is a patch against it - but has anyone ever actually done it on ESXi?

[Texiwill]

Hello,

See vmescape.com, but no, there have been no true VM escapes documented for ESXi. Workstation and ESXi are really separate beasts when it comes to how they protect themselves.

Best regards,

Edward L. Haletky

[TheVMinator]

Edward,

Thanks for the links.  Great input as always.  Great article on vmescape.com - also your article was great here as well.  Totally agree that this is the wrong issue to worry about.  However for those of us helping FUD-bound colleagues....

Although Mike's article was very good on this - if it has never happened on ESXi even internally at VMware, I wish he would come out and say "VM escape has never happened on ESXi" and make it clear.

He says "Is there a risk? Of course"

Also - the VMware security advisory says this:

VMSA-2017-0006

"ESXi, Workstation, Fusion have a heap buffer overflow and uninitialized stack memory usage in SVGA. These issues may allow a guest to execute code on the host."

For those of us trying to help FUD-bound colleagues -

If a FUD-bound CISO looking for a problem with VMware reading the security advisory, it would give ammunition to the argument that ESXi is vulnerable to VM escape.  It would have been more helpful for Mike to clarify like this:

"Even though VMware says that this critical vulnerability may allow a guest to execute code on the host [including ESXi], that this has only been done on Workstation and noone has ever done it on ESXi even within VMware's internal labs / testing"

Is there a reason he isn't saying it that emphatically?   Also it seems the most recent successful VM escape on workstation was flip feng shui (correct me if wrong)

https://www.vusec.net/projects/flip-feng-shui/

and would be helpful to explain in more specific technical detail why even though this exploit was done on workstation and a critical patch released by VMware for ESXi, that it could not and has not ever been executed on ESXi.

Thoughts?

[Texiwill]

Hello,

Patches are done as a proactive measure in many cases. Also, to dispel the possibility of an attempt to escape. If you look at my article mentioned on vmescape.com, I give the steps needed to do a vmescape on ESXi. It will take knowledge that very few people have to do.  However, you get to step 3 in that within VMware Workstation and you have Escaped to the operating system.  IN VMware ESXi, there is no 'operating system' you can see, so it is not possible in many cases to escape further down the stack. Getting into the VMM in ESXi is no-man's land. Nothing to latch onto.

Can Mike or I say unequivocally that there are no escapes in ESXi? No. the possibility will always exist, all VMware can do is play defense. I also bet they are playing offense in their own labs and hacking their own systems. I know their code is constantly pen-tested.

To do a proper escape you need to do all 8 steps, not stop at step 3 where you just cannot go anywhere else. In effect, an attack goes from inside the container to another part of the same container and no further. There have been a few driver issues that have gotten here, or even crashed the VM, but nothing has escaped the VM container.

Workstation and ESXi are WILDLY different at that level. A type 2 hypervisor is just not the same as a type 1 hypervisor. However, the VMM bits and some others are shared between them, that is why you see patches for both. It does not imply that the attack works but  the thought of why keep the potential available for misrepresentation.

Best regards,

Edward L. Haletky

[TheVMinator]

Edward,

Thanks again.  Helpful clarification.  The article you write was very helpful in describing the architecture of ESXi and why gaining control underneath the VM would be near impossible.  And it seems being not a security expert - (you can correct me here) - in the case of flip feng shui, the caveat is that you don't actually need to escape the VM.  A successful flip feng shui attack seems to be making certain types of physical servers with the right kind of physical RAM and running a hypervisor cough up memory contents outside of what is supposed to be dedicated to the VM, and allow that VM to read memory contents potentially belonging to another VM.

Obviously this creates some problems  - such as that without gaining control of the neighboring VM, the odds that I'm going to by chance force physical RAM contents that actually have something valuable (a username / password, sensitive data) in a format that is usable would be extremely small.

At the same time someone could argue that the confidentiality of data running in a VM had been compromised, even though noone actually "escaped" and took programmatic control of the ESXi hypervisor or of a vmm process on another vm.

So would you consider flip feng shui actually to be classified as a "VM Escape" or as another kind of attack?  It does seem to follow a different method than the process you referred to but if successful could still represent a compromise in security of an adjacent VM.

Would you say the same that there are no published accounts of a successful flip feng shui on ESXi?

[Texiwill]

Hello,

Okay, a few things. Memory in workstation is always shared with the OS upon which it runs, so workstation has this issue. ESXi VMs on the other hand do not share anything with anything with one sole exception. I will talk about that a bit later. However, due to CPU segmentation and other aspects of a type 1 hypervisor it is just not possible to go between VMs like that. You cannot grab memory outside your VM.

The exception to that is Transparent Page Sharing which is about sharing memory pages between VMs. When this happens the only data you can see is that which is identical between each VM. I.e. you would see it anyways if you did a memory dump. There is no new information there.

Type 2 hypervisors are limited by the OS in use. ESXi is not limited as such and protects itself far better. Once more, if you try to get memory outside your VM you get into the VMM which is a no-man's land. There is no overlap between VMs except where TPS is involved, and that is disabled by default these days. If you access, or try to access memory outside your VM you will get an access denied segmentation error and get nothing back.

Best regards,

Edward L. Haletky

[TheVMinator]

OK thanks for the reply.  I'd be curious what do you think about this article and how it applies or doesn't apply to ESXi?

https://www.vusec.net/projects/flip-feng-shui/