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."
It only affects the desktop systems. Interesting to see vulnerabilities finally start cropping up in the panacea virtualization techs.
But, this isn't a very big deal.
I have played with the shared folder feature, but never saw any real advantage over just using standard networking (SMB, NFS etc.) Is there some advantage to VMware's shared folder feature that I am too blind to see?
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.
This doesnt affect VMWare server though,which most people use in home settings (given that it is free)
Legally obligatory sig : My opinions are my own... etc etc
serious, even critical flaw, but still not -that- bad. A short term workaround involves turning off the file sharing feature.
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.
And the value in vmware is not 'high security' but 'high utilisation'. The ability to run multiple low load systems on one hardware platform, while not having to worry about package dependency, compatibility, or even that they run on the same OS. And the ease at which you can move one virtualized 'server' to another hardware instance, and other server management conviences.
VMWare as a security mechanism? Its pretty good I suppose. In theory you can approach the same level of security you would have by using separate boxes for the servers. But that's it... you can only approach, you're never going to reach parity, and you certainly aren't going to exceed it.
So VMWare is a security tradeoff... you trade a bit of security for better cash, space, and cpu utilisation.
That said, VMware security is quite good. Its a much smaller attack surface than, say, a chroot jail. But there is still an attack surface. If you want the highest possible security, dedicated hardware behind a firewall is, was, and probably always will be the best solution.
In closing, I'm sure we'll see a proper fix for this in short order.
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.
you have one CPU and you are asking it to both encrypt and decrypt a stream which can't be sniffed on the wire because it isn't going on the wire. I guess it is less silly on dual core or more where you could be encrypting on one core and decrypting on another. Either way it doesn't sound particularly efficient. That said if it is fast enough and you are familiar with it as a tool then please carry on.
About 8 years ago I was working at a dot-bomb that produced an "Intranet" solution. We weren't a huge company but we did have customers who deployed our product on their production web servers, as well we offered a "hosted" solution where we hosted the virtual desktop solution on our own servers.
One day a nice whitehat sent an e-mail to all@.com describing that he had found a buffer overflow in our CGI binary that could be exploited in order to get shell access with the permissions of whatever user the webserver was running as. He told us exactly how to exploit it but he did not provide any kind of proof-of-concept code.
Well, the main developer and maintainer of the CGI program (an extremely experienced and talented programmer who is, to this day, still one of the programmers that I look up to the most - for reasons other than what I am about to describe obviously) assured everyone in the company that exploiting such a programming error would be soooooo incredibly difficult that it was a complete non-issue.
Based on his assurances the whitehat was ignored and customers were never notified of the problem and many of them went on running a vulnerable application.
I tried explaining to everyone that buffer overflows in services were exploited all the time to gain remote access but I was a junior level programmer at the time and was ignored.
I imagine that had the whitehat provided us with exploit code that we could use to actually test the problem ourselves and demonstrate it to the "non-believers" then seriousness of the problem would have been forced and the issues would have gotten a lot more attention.
Anyway, of course Core could have provided the code to VMWare only, but the basic idea is that with exploit code in the wild it gives an extra push to get VMWare to fix the problem quickly.
whaaa?? vmware share folders have absolutly nothing to do with network shares..
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
In Beta they enabled their full drag and drop by default, but turned it off-by-default after a storm of protest on the Parallels forums. The reason for the protest is that they implemented the ability to do Mac-Windows drag and drop everywhere (instead of just to and from the Windows desktop) by creating a special magic UNC path that provided full local-user access to the root of the OS X file system.
As far as I know that's still in there, for both drag-and-drop and, if I recall correctly, for their "Coherence" mode where the Windows run in a pseudo-multi-window mode integrated to the Mac user interface.
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.
I'm always careful to run potentially vulnerable applications like this in a secure virtual environment.
Today's Sesame Street was brought to you by the number e.
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>
Just goes to show that you should always run VMWare in its own separate virtual machine (perhaps using Bochs or QEMU) to avoid security problems.
-- Ed Avis ed@membled.com
No, this is an example of a poor implementation of shared folders. This does not invalidate the use of virtual machines as a security mechanism. However, I will repeat what I said before on this subject: Virtualization solves an availability problem not a security problem.
He was lambasted for creating a controversy that didn't exist just so that he would be mention in the press. Theo is that you?
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...