Interesting security articles on VM's escaping into the host OS.

[esiebert7625]

Came across these the other days, some interesting reads...

Escaping from the virtualization cave - http://www.pauldotcom.com/2007/07/31/escaping_from_the_virtualizati.html

VM Escape Publicized at SANSFire 2007 - http://www.foolmoon.net/cgi-bin/blog/index.cgi?mode=viewone&blog=1185593255

An Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments - http://taviso.decsystem.org/virtsec.pdf

On the Cutting Edge: Thwarting Virtual Machine Detection - http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf

[oreeh]

Very interesting.

I'd love to hear a feedback from VMware on this.

[TomHowarth]

Interesting thing is they do not mention the OS version, but reading emperically it seems that the testing wast done on Hosted environments not ESX.

Taken from http://taviso.decsystem.org/virtsec.pdf

A. Test platform

All tests were performed on a typical commodity system, a

Pentium IV 3.2GHz running a Linux 2.6 based operating system,

with the exception of Virtual Machine Y which only supports

Microsoft Windows hosts. All virtual machines tested

were the latest versions available at the time of writing and

used in their default configuration state where possible. When

some minimal configuration was required, the options selected

have been described in the relevant sections.

All flaws identified as a result of this investigation were

reported to the respective developers. In the case of open

source implementations, patches were provided.

Two vendors were unable to respond to the reports presented

in time for publication, so the names of their products

have been obscured in the remainder of this paper.

Does anybody care to answer????

[Texiwill]

Hello,

The big question is any of this possible on ESX....

Directory Traversal vulnerability makes use of the vmhgfs driver, this can not be used within ESX so I am not sure it applies.

So that leaves the ability to crash a VM and to fuzz the IO. Which could be possible...

Yet, one that is not mentioned is the HVM vulnerability... www.theta44.org/software/HVM_Rootkits_ddz_bh-usa-06.pdf

Best regards,

Edward

[esiebert7625]

Yeah they're pretty vague on whether or not it would work on ESX.

This one is interesting also...

Subverting the Windows Kernel for Fun and Profit - http://invisiblethings.org/papers/joanna%20rutkowska%20-%20subverting%20vista%20kernel.ppt

Message was edited by:

esiebert7625

[jurajfox]

These exploits seem to be based on VMware products running on a host OS lke Workstation and Server... however we're all waiting for an ESX vmkernel level exploit to pop up...which could be quite devastating.

I've been focuing on hardeneing the service console and virtual center since this is the component that has the potential to cause alot of damage if compromised.

[Texiwill]

Hello,

This is exactly what you should do, that and ensure VM isolation and vSwitch settings are properly secured.

Best regards,

Edward

[GarionBrown]

So far this is not possible on ESX. Vmware says so in this blog;

http://blogs.vmware.com/vmtn/2007/08/being-escorted-.html

"As alluded to earlier, this issue doesn’t exist with ESX Server, since the “host” in this case is a purpose-built, thin, light-weight kernel which only runs code that ships with the product (for more information, see this white paper on the security architecture of VMware Infrastructure 3). There is neither any mechanism nor any reason for transferring files from the guest to this “host” OS. "

[Texiwill]

Hello,

Some of this is still possible if your ESX server is also a Samba or NFS Server.... Which it should never be, but people do it anyways..... It is a weakness in CIFS/NFS. A properly setup ESX server is not at risk for most of these attacks. However, we all know the improperly setup ESX Servers exist.

Best regards,

Edward

[esiebert7625]

Interesting response. ESX is a whole different product compared to Workstation and Server and alot more secure because VMware has total control over the Host OS.

On another note I found this recent article rather humourous...

http://www.securityfocus.com/news/11479

[TomHowarth]

Interesting article, It made me laugh too. :smileygrin:

[Texiwill]

Hello,

\*chuckle* That is very funny...

As for my response, I am only stating that a badly configured ESX system acting as a fileserver to VMs is still subject to the same limitations, threats, and vulnerabilities inherent in most of the protocols used for this, specifically CIFS. ESX provides all the tools necessary to be a file server and there are numerous discussion posts on setting this up, each hopefully with the warning not to do this, but as we know, people do it anyways.

Just like people place the SC inside a DMZ, which has a greater threat level than if it was placed within the corporate network behind its own firewalls, etc.

Best regards,

Edward

[esiebert7625]

Agreed, your environment is only as secure as you make it. ESX comes pretty secure out of the box but can be either made less secure or more secure depending on what is done by the admins.

[michael_40catbi]

Based solely on computational complexity, and the current state of the art regarding secure coding techniques, it is not possible for ESX to be defect free.

I can't say with the same certainty that any of these defects would allow a guest to break out and compromise the hypervisor.

However, as a gambling man and a security geek, I would not want to bet against the hackers on this one.

Rather than debate whether it is possible, we might be better off thinking about how to detect it when it happens.

[Texiwill]

Hello,

I would agree. Detection of a breakout/compromise is key and we can already detect most of the compromises there are. Unfortunately with the vmkernel being a 'black box' it is very hard to detect what would constitute a compromise at that level. We can most likely detect 'bad configurations' within the Service Console. But doing the same inside the vmkernel is much more difficult... Escaping to the host OS as discussed here could be an escape to the service console or a way to run arbitrary code within the vmkernel without the SC being involved....

I would put money on the hackers as well but their task it as complex as our own when it comes to prevention and monitoring. If you can not see inside the black box, how do we know? And if you could see inside, does that not itself change its state... Schroedinger's (sp) Cat comes to mine.

Best regards,

Edward

[esiebert7625]

if you're a sci-fi fan, both the cat and someone else have escaped the box, anyone know which books?