Critical VMware Vulnerability, Exploit Released
BaCa writes "Core Security has issued an advisory disclosing a vulnerability that could severely impact organizations relying on VMware's desktop virtualization software. It involves directory traversal using VMware's shared folders, and could allow an attacker access to the host system from a guest VM. Core also released an exploit for the vulnerability."
VMware's shared folders mechanism has always been a security hole waiting to happen (VMware's own docs pretty much admit that). I don't use them on servers at all, nor on any desktop where security has anything to do with the reason I'm using virtualization.
Mostly that it doesn't require you to configure folder sharing in the host OS. You enable folder sharing in the VM, and you don't have to add any additional services on the host.
Of course, if you're using desktop product (like VMWare Server) you can always do host-only networking and limit your shares to the host-only interfaces. But that's a little more work.
Oh, I almost forgot: if I'm not mistaken, folder sharing from inside VMware doesn't require any network access. So it works even if you turn of the network interfaces on the guest OS.
Yes, but if you RTFA you'll see that this vulnerability allows an attacker to access any part of the host file system, not just the shared files. That is bad.
And really, if you are running vmware for high security and server isolation you would NEVER have that on anyway. Because the existence of a shared folder is implicitly not isolation.
Actually, if you are running vmware for high security and server isolation you are running it on ESX, or at least VMware Server. Neither of which are vulnerable to this exploit.
Buttons aren't toys.
whaaa?? vmware share folders have absolutly nothing to do with network shares..
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
This is a great example of how virtual machines can actually reduce security (something that Theo de Raadt said not that long ago, and was lambasted for.) Here's a case where a local exploit in the guest could turn into a root exploit in the host--all by virtual of the fact that virtual machines (necessarily) run as root on the host. Even if they didn't run as root, it would allow two local exploits (one on the guest and one on the host), and presumably the possible infection of other guests running under the same local user.
it doesn't traverse the switch as i've tested by making a little loopback cable (rj45 connector with a couple of wires twisted) that is sufficient to fool the nic into a link-up state - but not actually be connected to anything and ssh (etc) still works between host and guests in bridged mode.
it definitely goes through the host's network stack, which is inefficient but convenient i guess.
its actually bloody annoying that vmware pays any attention to the hosts nic's link state, as if you're not connected to a switch/wlan, then you have no networking (unless you have a handy loopback cable!) and have to switch to host-only mode.
i'm getting a bit fed-up of vmware server though, especially that awful web gui in v2 beta, and they still haven't fixed the solaris10 networking issues that they've known about since before it was a "supported" guest os (try using nfs/jumpstart under vmware).
unfortunately i don't have the hardware to make xen/kvm useful, and virtualbox is a bit "unpolished" to be kind, seen bad reviews of parallels on the mac, so the linux version is probably worse.
#include <sig.h>