Slashdot Mirror
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.
I'm sick of following my dreams. I'm just going to ask where they're goin' and hook up with 'em later.
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.
I would think that there are quite a few desktop users in helpdesk settings, or some of them just curious, that use virtualization with the specific purpose of checking out possibly malicious software. As others have noted, some of them might even have turn networking off, with the intent of stopping phone-home or explicit attacks from the VM.
that is very true - very useful for virus / back door testing.. gives you a way of getting files onto the image without it being able to spread them (also without having to burn a disk - which would be another way)
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
whaaa?? vmware share folders have absolutly nothing to do with network shares..
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
Are people still taking the jerk seriously? His follow up article is horrible. He says he never mentioned "directory traversal", yet he did. He even says "I told about it before, you can't do anything useful with it." So, this "serious" problem is no big deal. He says now that Firefox could be "vulnerable by default" if there is another problem to compound this minor one. Sure, I agree that fixing minor bugs is important for security, but there is no vulnerability here, just an tempest in a teapot.
The description says basically that Windows' MultiByteToWideChar takes invalid UTF8 and unless you specifically tell it not to it allows errors such as expressing 7-bit characters as several bytes (or probably also allowing the longer variations of any character). Valid UTF8 only allows the smallest possible representation of a character. So vmware checks for "..", but the string is really more like "{4 zero bit}.{4 zero bits}." that when converted from utf8 to wide becomes just "..".
So this not likely to affect unix as well, where mbsrtowcs function stops on invalid sequences. In my view Microsoft is more to blame for this defect than the vmware authors since Microsoft created a function that hides input errors by default. The whole reason why UTF8 only allows the minimal representation is entirely to avoid these kinds of ambiguities and errors.
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>
Exactly, many people will sell you tons of software to *improve* your security when that software itself is generally the source of many vulnerabilities. Virtualization software is on example, the other, that surprised me when i found out, was anti-virus software.
Every software layer has bugs, and a sizable number of these bugs, are explotable security bugs.
PS: I work for Core Security with those guys. Kudos to Gera who discovered and Nico who Exploited it!
Burn a disk? Don't you mean create an ISO and mount it? VMWare, as well as many other virtualization apps, support mounting ISOs out of the box with no modifications to the guest OS. Why waste a CD, and all the extra effort when the easy answer is sitting right in front of you?