Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Critical VMware Vulnerability, Exploit Released

kdawson posted more than 6 years ago | from the heads-up-incoming dept.

Security 104

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."

cancel ×

104 comments

Sorry! There are no comments related to the filter you selected.

Limited issue (3, Interesting)

nhtshot (198470) | more than 6 years ago | (#22591936)

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.

Re:Limited issue (4, Insightful)

Brian Gordon (987471) | more than 6 years ago | (#22592652)

Anyone using Shared Folders is just asking for trouble anyway.. any sort of production setup will have a proper virtual network.

Re:Limited issue (1)

nurb432 (527695) | more than 6 years ago | (#22593374)

That was my first thought as well, would have to be an amateur running the show.

Re:Limited issue (1)

marafa (745042) | more than 6 years ago | (#22597098)

what? shared folders in a production environment? thats like begging for trouble

Re:Limited issue (1)

Gewalt (1200451) | more than 6 years ago | (#22593750)

Not sure if this is offtopic or not...

But on VMWare Fusion, I use the shared folder feature to map my mac's home drive in windows xp. Why? Because for security reasons, I don't have any other file sharing enabled on my mac.

Re:Limited issue (1)

TopSpin (753) | more than 6 years ago | (#22594914)

Anyone using Shared Folders is just asking for trouble anyway
I second that. Shared Folders is a bad idea and shouldn't exist. I suspect some "big customer" has VMware convinced the sky will fall should they not provide f<bleep/>ing Shared Folders. I hope that customer gets badly owned by this nonsense. You deserve it. This is purely self-inflicted and you should be laughed at and fired. With any luck the PHB you work for cracks his own jaw with the predictable knee jerk reaction and makes you put in a several weekends disabling every "Shared Folders" install you have and adapting your system to do without that stupid cop-out, as you should have done on day one. Enjoy.

Operating systems by definition provide one or more robust means of serving and consuming file systems and block devices. Why the f<bleep/>ck anyone thinks there must be a buggy, vulnerable and half-baked Shared Folders "feature" is beyond me. The fact that, among other bad ideas, I must explicitly hunt down and disable m<bleep/>r f<bleep/>ing Shared Folders (which is pathetically inflicted BY DEFAULT) on each and every Windows guest I deploy ensures my opinion of this species remains low.

Re:Limited issue (2, Interesting)

billcopc (196330) | more than 6 years ago | (#22595914)

Actually, I have a differing opinion.

I think VMware Shared Folders have a valid purpose, and the implementation isn't all bad. Having them as a virtual network share, I like. The problem with any feature, useful or not, is that some half-breed is going to misuse it to the extreme. That imbecile will get owned and blame the software because there's no possible way he could have made a stupid mistake.

I think such fools should be put on display. The idiot who used Shared Folders in a production environment, needs to be hung out to dry and hopefully fired from his job because clearly he does not understand the finer intricacies of operating a networked computer.

Me, I like Shared Folders. They're handy on the few occasions when actually use them. I would rather see people quit screaming over this exploit, wait a day for a fix to be released (VMware's pretty decent on important updates), then carry on with their lives. Let's be honest here: Shared Folders are not something every user needs on a constant basis. There are a bunch of people who use VMware on servers, where these folders matter not. There's another bunch like myself who run a ton of virtualized OS'es for compatibility testing. Lastly, there's a handful of idiots who don't really know what they're doing, they just know their title and salary and are extremely good at putting the blame on others to protect that title and salary.

WINDOWS ONLY (1)

awpoopy (1054584) | more than 6 years ago | (#22600030)

This is a Microsoft only issue. Only the "windows" hosted VMware workstation is affected. Non of the Linux versions are affected. I know it could be considered flamebait, however it's just "clarification".

Why use the shared folder feature? (4, Insightful)

Mostly a lurker (634878) | more than 6 years ago | (#22591950)

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?

Re:Why use the shared folder feature? (5, Informative)

sammy baby (14909) | more than 6 years ago | (#22592084)

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.

Re:Why use the shared folder feature? (4, Informative)

sammy baby (14909) | more than 6 years ago | (#22592176)

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.

Re:Why use the shared folder feature? (2, Informative)

Amouth (879122) | more than 6 years ago | (#22592502)

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)

Re:Why use the shared folder feature? (2, Informative)

Grakun (706100) | more than 6 years ago | (#22595876)

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?

Re:Why use the shared folder feature? (1)

Amouth (879122) | more than 6 years ago | (#22599638)

i know i was just makeing a point why shared folders can be used.. makeing an ISO is just as much of a hassle as burning a disk (except yea you don't have to waist 10cents on a disk)

Re:Why use the shared folder feature? (1)

bazorg (911295) | more than 6 years ago | (#22592798)

fyi: VMplayer (not necessarily server) also allows configuring the VM to do host-only communications.

Re:Why use the shared folder feature? (0, Troll)

TopSpin (753) | more than 6 years ago | (#22595090)

and you don't have to add any additional services on the host.
Critical thinking isn't something you employ while earning your wage is it? Shared Folders IS AN ADDITIONAL SERVICE. A badly implemented one as well. You would know that if you actually observed the warnings that chronically appear among the system messages on Windows boxes that have this enabled.

On one hand you have robust, OS vendor provided mechanisms for sharing files. On the other you have some highly vertical third party hack with obvious chronic issues and now public exploits. Just what sort of a ****ing moron must you be to choose the latter?

Re:Why use the shared folder feature? (1)

0racle (667029) | more than 6 years ago | (#22592118)

It's more transparent to the user, there's no setup. Personally I just use standard networking.

Re:Why use the shared folder feature? (2, Informative)

milsoRgen (1016505) | more than 6 years ago | (#22592146)

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?
I was using MS's Virtual PC, and I used the shared folder's add on so that I could leave the networking disabled as I was afraid of certain software calling home.

Re:Why use the shared folder feature? (1)

grcumb (781340) | more than 6 years ago | (#22592600)

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?

Yes. 8^)

I'm a little conservative about security, so I run a snapshotted Windows XP under VMWare with the network interface disabled unless I absolutely need it. Shared folders allow me to access and save all the files I work on in this environment.

... Needless to say, I'll be re-evaluating my approach once I've had a chance to look at exactly how this directory traversal exploit works.

Re:Why use the shared folder feature? (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22593010)

I'm not sure conservative was the word you were looking for.

paranoid?
ignorant?
idiotic?

I hear it's even more secure if you leave the machine turned off entirely!

Re:Why use the shared folder feature? (0)

Anonymous Coward | more than 6 years ago | (#22593732)

Personally I would go with "pathetically nerdly".

Re:Why use the shared folder feature? (1)

Bill Dog (726542) | more than 6 years ago | (#22593600)

I just wish I could get this feature to work at all (on a Windows host). VMware Workstation 5.5 for Windows. No "VMware Shared Folders" appears in "My Network Places" in the VM'ed Windows OS. No "\\.host\Shared Folders" can be found by the VM'ed WinXP. Network is the only way. Maybe it works in v6.

Re:Why use the shared folder feature? (1)

Earthquake (4014) | more than 6 years ago | (#22593054)

One big advantage is that Shared Folders work even if networking support is disabled. You can, for example, set up a VM with no virtual NIC to simulate a PC with no Internet connection, or you can disable the virtual NIC, but you can still used Shared Folders to get at files on your host. Shared Folders also keeps working if your PC becomes disconnected from the network, where bridged connections do not.

Another advantage is Shared Folders use the security privileges of your HOST, not the GUEST. This can be useful to access Windows domain resources from a guest that isn't part of the domain. This can also be useful if your VM can't access the domain resources directly due to technical limitations (no support for Active Directory, etc). You can map domain resources onto the host, then share those resources using Shared Folders into the guest.

I mostly use VMware Workstation on Windows, but I'm sure there are similar situations on a Linux host/guest where the Shared Folders feature can let you work around networking issues if you just need to get some files in and out of the VM.

Re:Why use the shared folder feature? (1)

$pace6host (865145) | more than 6 years ago | (#22596766)

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?
Here's why I use it, maybe someone can recommend something better... When I telecommute, I do all my work in a VM. I don't want to mix my work files with my personal files, and I don't want to install the software required by my employer on my personal PC, where it can interfere with the software I've chosen for my personal use. So, I have VMWare Player with XP SP2 on it, running on my Ubuntu server. When I start up the VPN software my employer provides, it hijacks all the XP network interfaces, and everything gets sent over the VPN connection. For the most part, I can't get to any of the resources on my LAN, so SMB and NFS aren't an option. When I want to print something, I can't get to any printers except those 10 miles away at the office. So, I installed CutePDF, set up a shared folder, and run a script on the host that looks for PDF files in the shared folder.

Re:Why use the shared folder feature? (1)

Lavene (1025400) | more than 6 years ago | (#22597768)

... Is there some advantage to VMware's shared folder feature that I am too blind to see?
Yes, you can use it to gain access to the host system...

Don't do that, then! (5, Informative)

NNKK (218503) | more than 6 years ago | (#22591978)

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.

Re:Don't do that, then! (1)

link-error (143838) | more than 6 years ago | (#22592082)

VMPlayer doesn't support shared folders, which is what most people are probably using. VMWorkstation does, but I don't know how popular it is.

Re:Don't do that, then! (3, Informative)

Anonymous Coward | more than 6 years ago | (#22592430)

VMPlayer Does support shared folder, you just have to edit the .vmx file yourself...

Closed Source (0, Flamebait)

RAMMS+EIN (578166) | more than 6 years ago | (#22592038)

So...do we pounce on VMWare for being closed source and therefore _obviously_ insecure, now?

Re:Closed Source (1)

wizardforce (1005805) | more than 6 years ago | (#22592220)

So...do we pounce on VMWare for being closed source and therefore _obviously_ insecure, now?
no, we pounce on them if they don't bother to fix this... ever.
from TFA:

Successful exploitation requires that the Shared Folder's feature to be enabled which is the default on VMware products that have the feature AND at least one folder of the Host system is configured for sharing.
not only does this feature need to be enabled but you also have to configure at least one folder for sharing. makes sense. until it gets fixed, it is best to disable the shared folders feature and use another method that has not yet been compromised.

Re:Closed Source (0, Offtopic)

dragonsomnolent (978815) | more than 6 years ago | (#22592300)

I wonder if that includes the admin shares on Windows hosts

Re:Closed Source (4, Informative)

Amouth (879122) | more than 6 years ago | (#22592534)

whaaa?? vmware share folders have absolutly nothing to do with network shares..

Re:Closed Source (1)

dropadrop (1057046) | more than 6 years ago | (#22592688)

not only does this feature need to be enabled but you also have to configure at least one folder for sharing. makes sense. until it gets fixed, it is best to disable the shared folders feature and use another method that has not yet been compromised.

It's enabled by default though, at least in Fusion.

I'm tired of this closed source argument (0, Troll)

microbee (682094) | more than 6 years ago | (#22592266)

Last time I checked, the firefox 2.0.0.12 vulnerability [slashdot.org] was still not fixed. Funnily enough, more than one people in that thread said "given it's firefox/open source/blah blah, we should expect a fix within 24 hours". Like that had happened. And all the other wonderful things to say when you find bugs in an open source project [slashdot.org] .

Re:I'm tired of this closed source argument (1, Informative)

Anonymous Coward | more than 6 years ago | (#22592620)

Are people still taking the jerk seriously? His follow up [0x000000.com] 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.

Re:I'm tired of this closed source argument (1)

Anonymous Coward | more than 6 years ago | (#22593680)

If people used a real Web browser, preferably on a 100% secure OS like OS 10, these security issues would not be a problem.

a 100% secure OS like OS 10 (1)

spazdor (902907) | more than 6 years ago | (#22595210)

lol.

Re:I'm tired of this closed source argument (1)

Herby Sagues (925683) | more than 6 years ago | (#22595588)

That was a good one!

Re:I'm tired of this closed source argument (1)

Sancho (17056) | more than 6 years ago | (#22593108)

I'm pretty sad that this post got modded down so much. It really does expose a glaring fallacy--that open source is inherently more secure. Oh well, I've got Karma to burn.

It's true that more eyes can look at the code. It's true that anyone can try to fix it and then submit a patch. But it requires action for this to be the case. Firefox is a classic example of a major open source project which consistently has security holes left unpatched. It's a major project, people! It's practically the poster-child for alternatives to Microsoft software! Fix the damned bugs!

Re:I'm tired of this closed source argument (1)

palegray.net (1195047) | more than 6 years ago | (#22594810)

Please provide references to security holes left in Firefox for long periods of time. Note that other categories of bugs do not count (if it doesn't create a risk of exploit, it doesn't count). Thank you.

Re:I'm tired of this closed source argument (1)

microbee (682094) | more than 6 years ago | (#22595762)

See grandparent, the one marked as Troll.

Not that I care too much about how my comment is modded (let me just say I don't feel sorry for other people's stupidity), but it's still a bit sad to see that a comment with _material_ (no matter what the opinion is) gets this kind of treatment.

Re:I'm tired of this closed source argument (1)

Nicolay77 (258497) | more than 6 years ago | (#22594356)

I totally agree with you. Sadly I don't mod anymore.

Re:Closed Source (0)

Anonymous Coward | more than 6 years ago | (#22592292)

Well, at least you're not jumping to conclusions.

Re:Closed Source (1)

SQLGuru (980662) | more than 6 years ago | (#22592386)

But if you *ARE* jumping to conclusions, you probably need the official "Jump to Conclusions" mat available in the Office Space kit ahref=http://www.thinkgeek.com/books/humor/8e6c/rel=url2html-12174 [slashdot.org] http://www.thinkgeek.com/books/humor/8e6c/>.

Layne

Re:Closed Source (1)

Amouth (879122) | more than 6 years ago | (#22592566)

for once my sig aplies to someone's comment..

Re:Closed Source (1)

dens (98172) | more than 6 years ago | (#22592338)

What a load of crap! Why would an obvious BS troll like that get a positive score? ...oh, right, I almost forgot what site I'm on.

Best to use SSH... (1)

Yaa 101 (664725) | more than 6 years ago | (#22592052)

I always use SSH as transfer between the host and guest environment, yes it is slower but so much saver.

Re:Best to use SSH... (2, Insightful)

dominux (731134) | more than 6 years ago | (#22592324)

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.

Re:Best to use SSH... (1)

Sancho (17056) | more than 6 years ago | (#22593140)

I'm not the original poster, but this comment made me think.

First of all, what if you're bridging? Does the OS snag the packet that's destined for its interface, or does it forward to the switch first?

Second, lots of people don't set up FTP anymore, due to better alternatives. What other options would you use? You could use Samba--again, if you have it set up.

Usually, I'd also use scp, but I'd use a weak (and fast) encryption mechanism. It's a shame that OpenSSH got rid of the "no encryption" cipher. I've seen patches to put it back in, but that's a pain to manage.

Re:Best to use SSH... (1)

Professor_UNIX (867045) | more than 6 years ago | (#22593264)

It's a bridge, it's not going to send data out the NIC if it has the MAC address of the virtual machine in its virtual bridge's table. At worst it may flood a couple of packets.

Re:Best to use SSH... (1)

Sancho (17056) | more than 6 years ago | (#22593452)

You can't assume that in software. A software implementation of a bridge might simply send packets out the interface which is connected to the live wire. I've seen similar (bad) implementations in code which purports to act as a bridge. The bug was originally noticed when connections through the bridge back to the host couldn't be made, since the switch received packets on the same port to which they should be forwarded.

Re:Best to use SSH... (5, Informative)

BestNicksRTaken (582194) | more than 6 years ago | (#22593914)

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.

Re:Best to use SSH... (1)

Sancho (17056) | more than 6 years ago | (#22594148)

Good to hear.

It's sad that there aren't any good, robust virtual machine solutions out there. VMWare really does seem to be the best on all platforms, though trying to use anything non-Windows/Linux is probably going to be frustrating.

Xen really isn't much better. They have support for Windows on machines with hardware virtualization instructions, but more obscure operating systems just don't get support.

Re:Best to use SSH... (1)

entmike (469980) | more than 6 years ago | (#22592966)

I don't see the point of this at all.

Shared folders can spread malicious code? NO WAI! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22592058)

My dick smells like fish.

Not the default on my copy of 6.0.2 (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#22592064)

You have to enable shared folders and actually set at least one folder to be shared to exploit.

On my copy of vmware there is a big exclamation that this could be risky. Creating a new VM has the feature disabled by default.

Duh? (0, Redundant)

Mesa MIke (1193721) | more than 6 years ago | (#22592068)

Isn't the purpose of "shared folders" to allow access to the host file system from the VM?

Re:Duh? (5, Informative)

spud603 (832173) | more than 6 years ago | (#22592222)

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.

Re:Duh? (4, Informative)

Sancho (17056) | more than 6 years ago | (#22593176)

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.

Re:Duh? (1)

superskippy (772852) | more than 6 years ago | (#22594858)

Why do VMs have to run as root?

Re:Duh? (1)

Sancho (17056) | more than 6 years ago | (#22595088)

Generally, they access privileged instructions and memory, and they run code directly on the processor. A pure software emulator would not have this requirement.

Re:Duh? (2, Interesting)

Bill_the_Engineer (772575) | more than 6 years ago | (#22594934)

This is a great example of how virtual machines can actually reduce security

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.

(something that Theo de Raadt said not that long ago, and was lambasted for.)

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?

Re:Duh? (1)

Sancho (17056) | more than 6 years ago | (#22595098)

Ad hominem attacks are great for when you don't actually have a point to make, aren't they? Thanks for showing yourself to be the troll that you are.

Re:Duh? (2, Informative)

cachimaster (127194) | more than 6 years ago | (#22595338)

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!

Re:Duh? (1)

grasshoppa (657393) | more than 6 years ago | (#22596890)

Forgive me, but "no shit". Any process you run on your machine reduces security by it's very nature. However, it's still true that there is an overall net gain in security by wrapping up highly exposed processes in a VM and calling it a day ( sendmail anyone? ). While it's true that VMs are software and software has bugs ( always has and always will ), compare gaining access to a guest OS with gaining access to the host OS ( which, any OS running without a guest is considered for the purposes of this discussion ). In a guest, you would still have to exploit a bug which hasn't been patched to gain access to the host, and then you may still be limited depending on the particular exploit involved.

Theo may have had a valid point, I haven't read his comments, but the fact of the matter is that VMs are inherently more secure than running the service straight on the host.

SUP 4CHAN? (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22592104)

/g/ sucks the fat one.

HOW DID I TECH SUPPORT?


Lameness filter encountered. Post aborted!
Reason: Don't use so many caps. It's like YELLING.

Doesnt affect Server (2, Interesting)

quo_vadis (889902) | more than 6 years ago | (#22592132)

This doesnt affect VMWare server though,which most people use in home settings (given that it is free)

Re:Doesnt affect Server (1)

argent (18001) | more than 6 years ago | (#22592678)

VMWare Player is free too, and supports limited video acceleration. It's what I use to convince Photoshop 4 to let me run it when I need to poke around in actual .PSD files (it freaks out and tell me that I need more than 256M RAM if I run it with the full 2GB).

Re:Doesnt affect Server (1)

0racle (667029) | more than 6 years ago | (#22592682)

I would be willing to bet most VMware in the home usage is VMware Player which is also free and has better graphical performance. Both Player 1 and Player 2 on Windows are affected.

Exploit code released? (1)

Last_Available_Usern (756093) | more than 6 years ago | (#22592184)

The site announcing the vuln seems rather respectful. Why on earth would they release the PoC code to the public (non-compiled and thus easy to integrate) instead of just *saying* they had tested and proven it and sent the code and their findings to VMWare? I guess it generates more clicks and thus more ad revenue, but still.

Re:Exploit code released? (4, Interesting)

garett_spencley (193892) | more than 6 years ago | (#22592510)

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.

Re:Exploit code released? (1)

Amouth (879122) | more than 6 years ago | (#22592636)

well if you read the whole thing they have a time line from first notcing to notifying VMware and refining the problem all the way to posting the POC..

personaly i like it when they post POC's as it not only lets others see how they do it on paper insetead of in rough idea's or theory.

someone else might read the POC and see how it is exloiting this and realize that it can be used to effect something else and then inform people about that.

keeping the nature of the problem hiden from the public does not help create a world where everyone can contribute to makeing things secure.

serious, even critical flaw, but still not (5, Insightful)

vux984 (928602) | more than 6 years ago | (#22592202)

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.

Re:serious, even critical flaw, but still not (5, Informative)

theotherbastard (939373) | more than 6 years ago | (#22592240)

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.

Re:serious, even critical flaw, but still not (2, Informative)

cnettel (836611) | more than 6 years ago | (#22592418)

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.

Re:serious, even critical flaw, but still not (2, Informative)

0xABADC0DA (867955) | more than 6 years ago | (#22592754)

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.
You're probably also running it on a unix.

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.

I currently have (1)

Colin Smith (2679) | more than 6 years ago | (#22592424)

A load balanced network of highly available virtual servers running on my laptop...

Does that make me a bad person?
 

Re:I currently have (1)

tcopeland (32225) | more than 6 years ago | (#22592774)

> A load balanced network of highly available virtual servers running on my laptop.

Nice! I'm working on Capistrano deployment stuff and so my Macbook is running a couple of FC8 VMs. It's not happy about it either...

No one should be surprised (1)

Thelasko (1196535) | more than 6 years ago | (#22592466)

Every piece of documentation I ever read tells you that the file sharing feature is risky and to avoid using it. Call me when they find a vulnerability in VMwaretools. I won't be surprised with that either, but other people might. The mere presence of VMwaretools on a OS tells an intruder that there is a bigger fish to catch nearby.

Re:No one should be surprised (0)

Anonymous Coward | more than 6 years ago | (#22592748)

That is true, but the absence of VMwaretools is no better. It is trivial (for a C programmer at least) to detect you are running in a VMware or Virtual PC/Server VM. (Last I checked anyway.)

Re:No one should be surprised (1)

rdradar (1110795) | more than 6 years ago | (#22592756)

You do not even need vmwaretools to detect if its running inside vmware. Theres small differences in memory and virus creators have used these tricks for long to mess around with antivirus companies trying to figure out how the virus works and what it does. For example this code [pastebin.com] also detects if running inside vmware

Re:No one should be surprised (1)

Thelasko (1196535) | more than 6 years ago | (#22592806)

Thanks for the info!

Re:No one should be surprised (1)

InsaneGeek (175763) | more than 6 years ago | (#22594414)

Much easier method:

cat /proc/scsi/scsi
Attached devices:
Host: scsi2 Channel: 00 Id: 00 Lun: 00
    Vendor: VMware, Model: VMware Virtual S Rev: 1.0
    Type: Direct-Access ANSI SCSI revision: 02

Not as vulnerable as you might think. (1)

DavidKlemke (1048264) | more than 6 years ago | (#22592588)

Vulnerable packages All versions of VMware's desktop products that include the Shared Folders feature up to: * VMWare Workstation 6.0.2 * VMWare Workstation 5.5.4 * VMWare Player 2.0.2 * VMWare Player 1.0.4 * VMWare ACE 2.0.2 * VMWare ACE 1.0.2 Non-vulnerable packages * VMWare ESX * VMWare Server
So in reality the systems that are affected are really only the desktop solutions and not the server solutions that the majority of places would use. Hell, even everyone who's downloaded VMWare Server for free is protected! I'd say the majority of users aren't affected at all by this exploit. Unless you're stupid enough to use the affected products in production environments (don't laugh, I know places that do).

Re:Not as vulnerable as you might think. (1)

argent (18001) | more than 6 years ago | (#22592642)

A lot more people use the desktop versions than you seem to think, and quite a few folks use them for testing of software they think might be suspect. I don't know why you would use shared folders in that environment but it's a good thing to be reminded that shared folders are inherently a security hole (albeit one not so large as this, normally).

Companies rely on ESX, not desktop virtualization (1)

ajquirk (1248110) | more than 6 years ago | (#22592692)

I understand it's a problem if there are vulnerabilities in the desktop virtualization products. However, I am not sure how many organizations are relying on the desktop products for secure and isolated computing. Enterprises depend upon VMWare's ESX Server and the Virtual Infrastructure products to perform large scale production consolidation where security is a huge factor. In my experience, VMWare Workstation, Server and Player are used as development platforms, where isolation is not as important.

Parallels Desktop has a similar problem... (4, Interesting)

argent (18001) | more than 6 years ago | (#22592762)

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.

ESX unaffected from this exploit (1)

cyberblob (61687) | more than 6 years ago | (#22592926)

But for those of us using an ESX environment this is not a problem.

Obligatory XKCD (1)

BrianGKUAC (919321) | more than 6 years ago | (#22593012)

So this [xkcd.com] might not be so safe after all?

Sounds like.. (0)

Anonymous Coward | more than 6 years ago | (#22593096)

Sherlock Holmes has escaped the Holo-deck!!!

On by default? (1)

Aurthur (1248138) | more than 6 years ago | (#22593186)

FTA:

To maintain and improve user inter-operation with virtualized and non-virtualized systems VMware's software implements a number of inter-system communication features. The Shared Folder mechanism is one of such features and is enabled by default in all VMware's products that provide it.
This is quite simply an incorrect statement. VMware Workstation and Player do not use shared folders by default and have no default shared folders. All of this has to be deliberately set up. However, once you have set up folder sharing, those settings will follow the guest VM if you move it to another system, so it is imperative that you verify the settings of a VM you did not yourself build before using it.

No Problem For Me (3, Funny)

Zordak (123132) | more than 6 years ago | (#22593644)

I'm always careful to run potentially vulnerable applications like this in a secure virtual environment.

Does this really impact many people? (1)

93 Escort Wagon (326346) | more than 6 years ago | (#22593738)

If I read the description correctly, it's a local exploit - the advisory says it's remotely exploitable, but it sounds like a remote user would have to be able to log into your virtualized system (using something like RDP). It seems like it'd be unusual to allow remote users to connect to a virtualized OS on a desktop.

On those rare instances I run VMware Fusion, it's NATted. Fortunately the main use I have for Windows anymore is just to test web page breakage on IE.

first post (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22594100)

for the sTate of [goat.cx]

More virtualization is the answer (2, Funny)

Ed Avis (5917) | more than 6 years ago | (#22594572)

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.

Anyone notice how Linux hosts aren't vulnerable? (1)

Schraegstrichpunkt (931443) | more than 6 years ago | (#22594730)

Only Windows hosts are vulnerable. Linux hosts aren't. Why is that?

Answer: On Linux, no MultiByteToWideChar conversion is necessary, so the VMware developers can't screw it up.

VMware developers are at fault, but Microsoft's complicated design shares some of the blame.

Microsoft boasts a great user interface, but the interface they provide to developers (developers, developers, Steve!) is utter crap.

Yeesh.

Update: Microsoft is irresponsible, as usual (1)

Schraegstrichpunkt (931443) | more than 6 years ago | (#22594828)

Update: Microsoft is more at fault than I thought. Apparently MultiByteToWideChar decodes overlong forms of UTF-8, thus (irresponsibly, IMHO) violating RFC 3629 and allowing this problem to occur in the first place.

VMware should have been able to trust the OS to do proper UTF-8 decoding.

Short Short version (1)

CokeJunky (51666) | more than 6 years ago | (#22595230)

If you run one of the affected VMWare products, and have host folder sharing enabled, and run either a piece of software or a trojan horse virtual machine(i.e. that you downloaded or otherwise shared) with exploit code in in it, then that software can access your host machine with elavated privledges to at the very least the same as the logged in user on the host machine, and possibly to the administrator level.

Essentially what it says is that the vmware host folder sharing mechanism does not properly limit access to the host machine to the mapped folders -- tricks in how MCBS-Unicode conversions take place allow a carefully encoded path to include ..'s in it that are not filtered out or caught by vmware, and therefore access anywhere on the host machine with the same privledges as the VMware host software.

Workaround: Disable host folder sharing, and be careful about how much you trust shared VM's and software running on a VM image you build yourself.

::sigh:: (1)

cyberfr0g (2812) | more than 6 years ago | (#22599334)

This is like a builder who builds a house without any doors or windows in a bad neighborhood while telling the buyers "YOU DON'T HAVE ANY DOORS OR WINDOWS ON YOUR HOUSE SO DON'T PUT ANYTHING VALUABLE IN HERE" and local burglars taking 5 or 6 years to realize it. You deserve to have all your stuff stolen because you didn't bother to look at your own place or take the builders warnings to heart.

This whole situation couldn't be more irrelevent, just like this comment.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?