donlee
Contributor
Contributor

VM Escape?

Jump to solution

Hello, I am being asked by the security team to split my nine-host DRS-HA cluster into 3 three-host DRS-HA clusters because they want to classify each cluster to a different security zone. They are saying that virtual machines of different security zones cannot be on the same host because of a vulnerability in VMware that allows a hacker to "escape the VM" and attack the host and other virtual machines from within a VM. Is this true with ESX server? I am not seeing any particular documentation of this vulnerability and under what circumstances this vunerability can take place. I need specifics, I really dont want to split up my server farm!

Thanks for any info you can give,

Don

0 Kudos
1 Solution

Accepted Solutions
sepso
Enthusiast
Enthusiast

The particular vulnerability that they are likely talking about does not affect ESX. See this KB article for more details:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100403...

View solution in original post

0 Kudos
12 Replies
blackcivic
Contributor
Contributor

this applies to GSX and vmware player and another version of vmware but here is the link... I think it refers to what you are looking for..

http://www.eweek.com/c/a/Security/VMWare-Virtual-Machine-Security-Flaw-Very-Serious/

sepso
Enthusiast
Enthusiast

The particular vulnerability that they are likely talking about does not affect ESX. See this KB article for more details:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100403...

0 Kudos
Texiwill
Leadership
Leadership

Hello,

The discussion is on http://blogs.zdnet.com/security/?p=902, and this is NOT new. It has been around since vmhgfs was first used within Workstation (several years now). It is a directory traversal attack that affects only the use of vmhgfs and badly configured hosts (where they are also CIFS/NFS fileservers for VMs).

The vmhgfs attack only affects Workstation, Player, ACE, and some versions of VMware Server. If does NOT affect ESX.

The CIFS/NFS attack has been around for ages (since CIFS/NFS was first used). This is why in VI3.5 /vmimages is no longer available as an option for mounting ISO/floppy files via the CDROM device and why your ESX server should never ever be a fileserver as well.

A default install/configuration of VI3/ESX Server does not suffer from this vulnerability.

There is no need to split up your VI3 cluster due to this report.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2022,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
donlee
Contributor
Contributor

Thanks guys, much appreciated!

0 Kudos
Chris_S_UK
Expert
Expert

there has just been published details of a vulnerability with certain VMware products whereby you can access the host's filesystem from within a guest but, crucially, ESX is not affected by this bug. see here:

I am not aware of anyone having managed to escape like this on ESX but it is certainly not outside the realms of possibility. In the environment where I work, we have had to implement a separate ESX host for the DMZ because our security policy did not allow what you are describing, so you are not alone!

I would ask your security guys if they can find any evidence of this having been achieved, as in "innocent until proven guilty"!

Chris

0 Kudos
Texiwill
Leadership
Leadership

Hello,

Due to other issues (the ability to move VMs from the Production network to the DMZ very easily) it is best practice at this time from a security perspective to always have a separate set of ESX hosts for a DMZ network. Mixing the two could lead to accidental or purposeful changes in which zone a VM lives. These subtle changes can happen easily and there are no protections in place to disallow the change within the VIC and definitely not from the SC. Nor is there any real detection of these changes.

As for using a directory traversal attack to access the ESX Host filesystem, unless your ESX service console is also a fileserver for use by the VMs there is absolutely no method by which this is possible. I have heard of various attempts to make this possible but with VI3/ESX there is no mechanism, even the /vmimages directory has been closed off in VI 3.5.

For VMware Server, Workstation, Player, ACE, etc, the solution is to disable vmhgfs within the VM using an isolation setting and you are no longer susceptible to the attack.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2022,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
Ripper98
Contributor
Contributor

Texiwill - Is the best practice you mentioned "separate set of ESX hosts for a DMZ network" published anywhere? I am having this same debate but I am having trouble finding a good source that makes this statement. I found a Gartner article which alludes to that fact but DISA and CIS don't have any mention of it. I even did a brief search of your book but couldn't locate it. I am trying to make a case for this in our environment and suprisingly getting kick back from security saying the risks aren't valid since there hasn't been a documented escape from ESX. Any help would be appreciated.

0 Kudos
Texiwill
Leadership
Leadership

Hello,

Check out http://www.vmware.com/files/pdf/dmz_virtualization_vmware_infra_wp.pdf as well as my own book on the subject.


Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]

Also available 'VMWare ESX Server in the Enterprise'[/url]

Blogging: The Virtualization Practice[/url]|Blue Gears[/url]|TechTarget[/url]|Network World[/url]

Podcast: Virtualization Security Round Table Podcast[/url]|Twitter: Texiwll[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2022,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
Ripper98
Contributor
Contributor

Thank you for the response. I found the documnet you supplied. We are utilizing the collapsed environment as shown in the best practice document which has internal and external facing systems co-mingled on the same ESX host. I am recommending we separate these on physically separate ESX hosts. I was hoping there would have been a document saying separation was the best practice without having the fully collaposed environment as an option. In the fully collapsed environment, as described in the document, isn't there a risk that an externally facing machine could allow a machine escape and get to the other systems in the event a vulnerability is discovered in the future? This is my main driving point for the physical versus the logical separtation as shown in the fully colapsed environment. In my mind software is fallable and should be planned for when feasible. Thanks again for getting back to me.

0 Kudos
Texiwill
Leadership
Leadership

Hello,

VM escapes in ESX in my mind are purely theoretical at the moment. Is it a Risk, yes. Is it a high risk? Is it something attackers and researchers are researching? Absolutely. But think about ESX for a moment? If you were to Escape the VM what would you see?

You would NOT see the Service Console as that runs within another VM.

You would NOT see a shell as there is not one directly within the hypervisor.

You would SEE memory objects but whose depends on how deep the penetration is. There is quite a few things that an attack would need to break through to get to anything juicy. Most known attacks are against paravirtualized drivers. if you do not install any paravirtualized drivers (pretty much VMware Tools) then this attack vector does not exist anymore. Granted for VMware View and VDI installs at least the vga paravirtualized driver is a requirement and is the most attacked on ESX. Many people are against this draconian action however.

You can mitigate the known attacks but as you say, you need to plan for the future. But remember this, even with a DMZ within the VMs, you have a separate Virtualization Administration zone within your Host. This zone contains the service console and other things. Therefore it is important to ensure credentials are different for all hosts as well as IDS/IPS are properly employed, etc.

The VM Escape that everyone is worried about just has not happened yet. WIll it? Probably? When? WHo knows. You can plan for it however and mitigate the possible attack points as best you can.


Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]

Also available 'VMWare ESX Server in the Enterprise'[/url]

Blogging: The Virtualization Practice[/url]|Blue Gears[/url]|TechTarget[/url]|Network World[/url]

Podcast: Virtualization Security Round Table Podcast[/url]|Twitter: Texiwll[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2022,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
Ripper98
Contributor
Contributor

Thanks so much for the information. Unfortunately I could not convince them to separate the DMZ from the production systems. Your description of what can be seen helps to ease some of my concern. I bought your book so hopefully I can be a little more informed for future recommendations.

Thanks again.

0 Kudos
Texiwill
Leadership
Leadership

Hello,

I learn something new about VM Escapes and what it would take nearly every day and it is not a requirement to separate the DMZ from production anymore.... With vSphere things are much better mainly do to VMsafe, but then you have new concerns.

In your case I would look towards mitigation, network protection, and increase auditing of your systems. I may even go so far as to impose Roles and Permissions on the DMZ network to prevent non-DMZ 'admins' from seeing the DMZ networks using Roles and Permissions within vCenter.


Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]

Also available 'VMWare ESX Server in the Enterprise'[/url]

Blogging: The Virtualization Practice[/url]|Blue Gears[/url]|TechTarget[/url]|Network World[/url]

Podcast: Virtualization Security Round Table Podcast[/url]|Twitter: Texiwll[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2022,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos