VMware Cloud Community
kellyre
Contributor
Contributor

Breaking out of guest OS

A while back someone told me about a way to break out of a guest OS into the host. Does anyone remember hearing this? Assuming that the host is secure and that only the VM is exposed, is it still possible to compromise the host OS from the guest?

If it is still possible, is there anything that can be done about it?

Reply
0 Kudos
29 Replies
larstr
Champion
Champion

I guess you're talking about the recent "VMware workstation guest isolation weaknesses"[/url]?

This is a minor issue.

The issue is in VMware workstation where you with an empty host clip board put focus in a VM that has an already filled up guest clipboard. Leaving that VM will also bring the guest clipboard into the host.

Lars

Reply
0 Kudos
kellyre
Contributor
Contributor

Thanks Larstr,

That does seem minor. I suppose someone could deliberately fill the guest clipboard and wait for someone to change focus back and forth, but then the person would probably refill the clipboard the next time they used it.

I was wondering about more serious leaks like using flaws in VMware tools or drivers that allow full control of the host. Things like a device driver buffer overflow, or a back door in VMware tools.

Reply
0 Kudos
devzero
Expert
Expert

i`m not a programmer, but i`m somewhat sure that this is possible and just a matter of time to be exploited.....

remember those hacking group "l0pht" ? they have given some nice statement when they had been active:

"That vulnerability is completely theoretical."

-- Microsoft

L0pht, Making the theoretical practical since 1992.

so - you just cannot be sure that a software is secure - sooner or later somebody may be able to break it - and the vendor needs to fix it.

Reply
0 Kudos
larstr
Champion
Champion

Very true indeed. Many software products that have been believed to be safe (as they had no vulnerabilities for years) have had serious vulnerabilities. Software is written by humans and humans make mistakes.

It's also a question of design and programming goals. OpenBSD have had 2 remote exploits[/url] during the last 10 years while other OSes such as the windows family have some more. OpenBSD used to have a slogan "Five years without a remote hole in the default install", but that still didn't mean it was 100% secure.

Virtualization software seems to be the next big focus for vulnerability research and we can expect issues (minor/major) popping up in the future. It's then (as always) important to keep your systems (guests & hosts) patched and to pay attention to any vulnerability reports regarding the products you're using.

Lars

Reply
0 Kudos
devzero
Expert
Expert

here is some interesting opinion from somebody @sun:

http://www.c0t0d0s0.org/archives/3058-Breachable-virtual-machines.html

Reply
0 Kudos
michael_40catbi
Enthusiast
Enthusiast

Recently, Microsoft posted this bulletin, MS07-049:

http://www.microsoft.com/technet/security/Bulletin/MS07-049.mspx

This bulletin describes a flaw, which allows an administrative user on the guest to break out of the guest and run commands on the host.

NOTE: this bulletin applies to Microsoft's virtualization environment ONLY.

I've added this here, because we must remember that today's theoretical attacks, often become real world exploits tomorrow.

IMHO, always treat guest break-out as a possibility and install security protection/monitoring accordingly

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

There was quite a bit of discussion on this at Black Hat this year and yes it is possible to "Escape the VM" when using a VM with a share mounted directly from the host either with vmhgfs or CIFS. The exploits are common in Windows land and are the primary 'escapes' used. Outside of known CIFS limitations and exploits there is no current method to escape the VM.

Best regards,

Edward

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

>Outside of known CIFS limitations and exploits there is no current method to

>escape the VM.

but there`s a method crashing it from the "inside" and still nobody told anything about if it`s exploitable or not.

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Crashing the OS from inside the VM is an exploit of sorts, but unrelated to the virtual hardware or virtual environment. It is extremely easy to crash a physical box unrelated to hardware, this does not change in the virtual world.

No virtualization software will protect you from exploitation of OS level bugs running within a Virtual Machine. The Virtual Machine will crash if you have the proper exploit just like physical hardware will. If the VM crashes there is no method to escape to the Host OS through the crash.

Best regards,

Edward

Message was edited by:

Texiwill

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

>Crashing the OS from inside the VM is an exploit of sorts

i`m not speaking about crashing an OS inside or outside a VM - i was speaking about crashing vmware-vmx(.exe)

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Yes that could also be considered an exploit but still does not escape you from the VM to the host..... vmware-vmx for workstation and vmware-server could crash due to improper handling of data sent to the hypervisor. If you new the VM was running vmware-vmx... then it may be possible to craft something but I have not heard of this happening yet.

From the ESX/VI3 perspective, vmware-vmx is just a communication layer between the SC and VM and if it dies you loose some control of the VM but not necessarily the VM. I have had my SC die on me due to a hardware issue but the VMs were happily chugging along. That is a nice feature to VI3.

Best regards,

Edward

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

The concerns raised in this thread seems to be reaching closer and closer to real life. sans.org just had a blog on the topic addressing some of the latest patches and there's an item there described as "A privileged user in a guest OS can execute arbitrary code on the host OS", also refering to a VMware bug report at the Fulldisclosure mailing list.

Related to ESX, it's only affecting packages in the Service Console, and seems not related to an exploit where you could break out of a VM to the SC or the kernel. This shows again the importance of locking down the Service Console.

For hosted products, it seems that an exploit from within the guest might allow for taking over the host:"allows authenticated users with administrative privileges on a guest operating system to corrupt memory and possibly execute arbitrary code on the host operating system"

It's probably just a matter of time before we see a similar exploit on ESX too. As the source of ESX isn't publicly available, creating a working exploit is probably a bit hard to implement, but that hasn't stopped people from doing the undoable before.

Lars

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

There are more serious issues that threaten ESX than escaping the VM which is theoretically possible but not available yet. There are various networking features that if not setup properly leave the host wide open to various forms of attacks.

The hackers are working feverishly to find an exploit that will work with ESX. But so far any exploit that may work, requires a misconfigured server to perform. The server out of the box is quite secure, but can be made much much better as always.

Can ESX be exploited right now? Yes, if ESX is misconfigured.

Can you escape the VM? Yes if the ESX server is misconfigured

Are there isolation issues in ESX just like Workstation? Yes

So currently in order to exploit you need badly configured ESX and isolation tools not disabled.

Moral: Changing the default security stance of your server puts you at risk. Not properly handling vSwitch networking puts you at risk.

Best regards,

Edward

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

Pardon me for jumping in, but I've been reading this thread with interest because we've just started on the path to virtualization with ESX server.

I see you talking about misconfigured ESX options, and also misconfigured vSwitches. I ran my install of a "stock" ESX server, and in fact I tightened it down a little by shutting down some services. I have 3 vSwitches - 1 for vMotion and SC traffic, 1 for one server subnet, and the third for a second server subnet. How would I know if something is misconfigured? I posted a question about my vSwitch setup elsewhere and no one said it looked bad. I would like more clarification on what you can misconfigure on the vSwitch or ESX server. Obviously opening up ports on the ESX server would be one thing (which as I said I haven't done), but beyond that, what are things to look out for, both for server configuration and for vSwitches.

On a side note, even though I have 3 vSwitches set up and I separate my SC/vMotion traffic onto it's own, the "behind-the-scenes" physical world has all traffic on the same subnet because it is the server subnet for both the ESX server and the other physical (and the now-virtual) servers. Does the SC/vMotion traffic need to be entirely on it's own subnet in the physical realm? We have firewalls and other things that lock down our server subnet and server IPs, so there is nothing getting into or out of the subnet other than the few ports necessary.

Thanks for any clarification you can give this newbie...

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

vMotion sends its data across the network in clear text. That implies that any machine on the subnet can read that data. It is EXTREMELY easy to do. vMotion Traffic should be 100% separate. About 70% of all attacks happen from inside your own network. The administrator sitting next to you could be the cause. With cleartext memory of a VM being sent over the wire it is possible to access credentials and other vital items about your users and clients. vMotion is extremely dangerous in an unprotected environment. I do not even need access to the SC to do it. I just did a Secure Coding class and we demonstrated something similar, it took less than 1 second to setup.....

SC and vMotion sharing the same subnet is also extremely dangerous. Not only do I have access to the vMotion but I can directly attack the SC and definitely your VMs with the credentials garnered. All that is needed is one weakness on your administrative network or the SC and the show is up.

The more data you make available to a hacker whether internal or external, the easier it is to break in.

If your ESX server is also a file server (NFS/CIFS or SMB) and your VM mounts those shares then it is possible to use a directory traversal attack to gain information about your system. ESX should never be a fileserver and is not configured as one by default.

Long story short, SC and vMotion, and non-admin VMs should NOT be on the same subnet. They should be 100% separate using either VLANs or separate pNICs.

Many people put the SC/vMotion on the same network depending on their external security and the honesty of the other admins. The super security conscious do not trust anyone.... You need to be comfortable with your levels of trust and what that implies.

Best regards,

Edward

Message was edited by: Texiwill

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

Thanks for the explanation.

You say "SC and vMotion, and non-admin VMs should be on the same subnet". I'm a little confused by that. It sounds like you're saying SC/vMotion and normal, accessible VMs should be on the same subnet. By the rest of your explanation it sounds like SC/vMotion should be on one subnet (with maybe an admin VM if needed), everything else on another. Just want to be sure I'm clear.

Another question I have is where you say it should be separated by VLANs or separate pNICs. I have 3 dual port NICs, and I set them up so that no single NIC runs all services for one thing, for reduncancy. So, for instance, SC/vMotion may be on a vSwitch using port 1 on NIC 1 teamed with port 2 on NIC 3. Similarly, another subnet may be on a vSwitch using port 2 on NIC 1 teamed with port 1 on NIC 3. If one NIC fails, there is still another one to keep everything going. I'm confused on how this is a bad thing. Are you saying that somehow someone can cross ports on a NIC to see what's on the other port?

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

My apologies, I corrected the post. They should NOT be on the same subnet. You really want at least 3 subnets utilizing up to 6 pNICs for redundancy.

2 for SC (failover only)

2 for vMotion (failover only)

2 for each VM Network (load balancing/failover modes)

If you have VLANs in use you can have 3 main VLANs and use less pNIC.

But yes, you would use all 3 dual port NICs which is 6 pNICs (Physical NIC). This would be the most secure setup from a networking perspective. Next make sure no VM can enter promiscuous mode, spoof MAC or IP.

Best regards,

Edward

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

How does one know if a VM can spoof a MAC or IP or enter promiscuous mode? Is there a setting I can use to prevent that? I have set up one VM up with the MAC address of the old physical box that was retired (using instructions found on this site written by esiebert7625) because we have vendor software that is set up to the MAC address, so if that is considered spoofing then I would have trouble with that one. Other than being able to set my IPs and MAC (if required), I would not want the VM to do any spoofing, nor would any of them need promiscuous mode.

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Look at the settings on your vSwitch and portgroup using the VIC. It is possible to deny the ability for a vNIC to go into promiscous mode (default), spoof a mac address or IP address. In ESX v2, these used to be available to just a VM but are now put directly on the portgroup/vSwitch.

Spoofing means that once the VM is running it tries to change its mac address. You can preset the mac address till within your VM Configuration file.

Best regards,

Edward

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