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

104 comments

  1. Limited issue by nhtshot · · Score: 3, Interesting

    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.

    1. Re:Limited issue by Brian+Gordon · · Score: 4, Insightful

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

    2. Re:Limited issue by nurb432 · · Score: 1

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

      --
      ---- Booth was a patriot ----
    3. Re:Limited issue by Gewalt · · Score: 0
      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.

      --
      Modding Trolls +1 inciteful since 1999
    4. Re:Limited issue by TopSpin · · Score: 1

      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.

      --
      Lurking at the bottom of the gravity well, getting old
    5. Re:Limited issue by billcopc · · Score: 2, Interesting

      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.

      --
      -Billco, Fnarg.com
    6. Re:Limited issue by marafa · · Score: 0

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

      --
      _ In Egypt Networks: Network Solutions with a Twist
    7. Re:Limited issue by Poltras · · Score: 1

      So what's your question? If you simply wanted to point that out, let me tell you you ARE asking for troubles. Share using network shares, not shared folders. It's as fast, as convenient and much more flexible and secure.

    8. Re:Limited issue by Jeruvy · · Score: 1

      Well SMB is used quite extensively in linux and windows circles so your argument is pretty ignorant of the problem. Instead you chose to go off on a Anti-MS rant about file sharing. Whoopie.

      When your head decides to reacquire air for your brain, you'll realize this affects linuxs guests just as easily as any others. The particular code has already been fixed except in the latest VW6 build, but the latest VW5 build is not affected, nor is ESX. The problem as well noted is in MB encoding practice and the methods used, not in 'file sharing', that just provided the framework to the exploit.

      --
      Jeruvy
  2. Why use the shared folder feature? by Mostly+a+lurker · · Score: 4, Insightful

    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?

    1. Re:Why use the shared folder feature? by sammy+baby · · Score: 5, Informative

      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.

    2. Re:Why use the shared folder feature? by 0racle · · Score: 1

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

      --
      "I use a Mac because I'm just better than you are."
    3. Re:Why use the shared folder feature? by milsoRgen · · Score: 2, Informative

      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.
      --
      I'm sick of following my dreams. I'm just going to ask where they're goin' and hook up with 'em later.
    4. Re:Why use the shared folder feature? by sammy+baby · · Score: 4, Informative

      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.

    5. Re:Why use the shared folder feature? by Amouth · · Score: 2, Informative

      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.'
    6. Re:Why use the shared folder feature? by grcumb · · Score: 1

      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.

      --
      Crumb's Corollary: Never bring a knife to a bun fight.
    7. Re:Why use the shared folder feature? by bazorg · · Score: 1

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

    8. Re:Why use the shared folder feature? by Earthquake · · Score: 1

      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.

    9. Re:Why use the shared folder feature? by Bill+Dog · · Score: 1

      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.

      --
      Attention zealots and haters: 00100 00100
    10. Re:Why use the shared folder feature? by Anonymous Coward · · Score: 0

      Personally I would go with "pathetically nerdly".

    11. Re:Why use the shared folder feature? by TopSpin · · Score: 0, Troll

      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?

      --
      Lurking at the bottom of the gravity well, getting old
    12. Re:Why use the shared folder feature? by Grakun · · Score: 2, Informative

      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?

    13. Re:Why use the shared folder feature? by $pace6host · · Score: 1

      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.
    14. Re:Why use the shared folder feature? by Lavene · · Score: 1

      ... 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...
    15. Re:Why use the shared folder feature? by Amouth · · Score: 1

      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)

      --
      '...if only "Jumping to a Conclusion" was an event in the Olympics.'
  3. Don't do that, then! by NNKK · · Score: 5, Informative

    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.

    1. Re:Don't do that, then! by link-error · · Score: 1

      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.

      --
      -Unresolved symbol? Byte me!
    2. Re:Don't do that, then! by Anonymous Coward · · Score: 3, Informative

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

  4. Closed Source by RAMMS+EIN · · Score: 0, Flamebait

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

    --
    Please correct me if I got my facts wrong.
    1. Re:Closed Source by wizardforce · · Score: 1

      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.
      --
      Sigs are too short to say anything truly profound so read the above post instead.
    2. Re:Closed Source by Anonymous Coward · · Score: 0

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

    3. Re:Closed Source by dragonsomnolent · · Score: 0, Offtopic

      I wonder if that includes the admin shares on Windows hosts

      --
      I got nuthin
    4. Re:Closed Source by dens · · Score: 1

      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.

    5. Re:Closed Source by SQLGuru · · Score: 1

      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-12174http://www.thinkgeek.com/books/humor/8e6c/>.

      Layne

    6. Re:Closed Source by Amouth · · Score: 4, Informative

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

      --
      '...if only "Jumping to a Conclusion" was an event in the Olympics.'
    7. Re:Closed Source by Amouth · · Score: 1

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

      --
      '...if only "Jumping to a Conclusion" was an event in the Olympics.'
    8. Re:Closed Source by dropadrop · · Score: 1

      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.

  5. Best to use SSH... by Yaa+101 · · Score: 1

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

    1. Re:Best to use SSH... by dominux · · Score: 2, Insightful

      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.

    2. Re:Best to use SSH... by entmike · · Score: 1

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

    3. Re:Best to use SSH... by Sancho · · Score: 1

      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.

    4. Re:Best to use SSH... by Professor_UNIX · · Score: 1

      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.

    5. Re:Best to use SSH... by Sancho · · Score: 1

      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.

    6. Re:Best to use SSH... by BestNicksRTaken · · Score: 5, Informative

      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>
    7. Re:Best to use SSH... by Sancho · · Score: 1

      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.

  6. Duh? by Mesa+MIke · · Score: 0, Redundant

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

    1. Re:Duh? by spud603 · · Score: 5, Informative

      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.

    2. Re:Duh? by Sancho · · Score: 4, Informative

      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.

    3. Re:Duh? by superskippy · · Score: 1

      Why do VMs have to run as root?

    4. Re:Duh? by Bill_the_Engineer · · Score: 2, Interesting

      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?

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    5. Re:Duh? by Sancho · · Score: 1

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

    6. Re:Duh? by Sancho · · Score: 1

      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.

    7. Re:Duh? by cachimaster · · Score: 1, Informative

      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!

    8. Re:Duh? by grasshoppa · · Score: 1

      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.

      --
      Mod me down with all of your hatred and your journey towards the dark side will be complete!
    9. Re:Duh? by Bill_the_Engineer · · Score: 1

      Ad hominem attack? No point being made? Troll? A little harsh don't cha think?

      BTW, in order for it to be an Ad hominem attack, I would have to say that Virtual Machines are secure because Theo is an idiot. I didn't say that, and I don't think Theo is an idiot.

      So let me break it down for you:

      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.

      My point was that VMware adding a poorly implemented feature called "shared folders" does not invalidate the argument that VM can be used to improve security.

      For example, If you chose to not use "shared folders" and instead used network services to access files on the host OS, you would have compartmentalized the risk from vulnerabilities to within the guest OS. You could further mitigate the risk by having automated backups and sane permissions applied to the shared files.

      I further repeated my stance that VM (in an enterprise setting) solves an availability problem, and was not really designed for improving security. Security was just a nice byproduct.

      I could have said "Your example is just as valid as saying 'Problems and exploits found in Windows are perfect examples of why using an operating system to run application software within a given hardware platform is a bad idea'." But that would have been silly, and not have added anything to the conversation but a smartass example of how one buggy VM doesn't invalidate all VMs.

      (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?

      I didn't attack Theo. I pointed out that Theo wasn't lambasted for his criticism of VM as a way of improving security, instead he was lambasted for the way the topic came about. Asking if you were Theo was a humorous jab...

      Anyway, the "lambasting" was like this fictional exchange between Jack, Jill and their peers (I know it's a silly oversimplification):

      Jack: Cardboard boxes make crappy apple pies!

      Jill: Of course, cardboard boxes make crappy apple pies. We didn't make the boxes to put in the pie, we made them so we can carry more than one pie at a time.

      Jack: Well I heard that some people were using cardboard boxes to make apple pies, and I wanted to voice my concern.

      Peers: Well Duh. We already knew the proper use of cardboard boxes. Way to keep yourself topical Jack.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
  7. Doesnt affect Server by quo_vadis · · Score: 2, Interesting

    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
    1. Re:Doesnt affect Server by argent · · Score: 1

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

    2. Re:Doesnt affect Server by 0racle · · Score: 1

      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.

      --
      "I use a Mac because I'm just better than you are."
  8. Exploit code released? by Last_Available_Usern · · Score: 1

    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.

    1. Re:Exploit code released? by garett_spencley · · Score: 4, Interesting

      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.

    2. Re:Exploit code released? by Amouth · · Score: 1

      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.

      --
      '...if only "Jumping to a Conclusion" was an event in the Olympics.'
  9. serious, even critical flaw, but still not by vux984 · · Score: 5, Insightful

    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.

    1. Re:serious, even critical flaw, but still not by theotherbastard · · Score: 5, Informative

      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.
    2. Re:serious, even critical flaw, but still not by cnettel · · Score: 2, Informative

      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.

    3. Re:serious, even critical flaw, but still not by 0xABADC0DA · · Score: 2, Informative

      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.
  10. I'm tired of this closed source argument by microbee · · Score: 0, Troll

    Last time I checked, the firefox 2.0.0.12 vulnerability 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.

    1. Re:I'm tired of this closed source argument by Anonymous Coward · · Score: 1, Informative

      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.

    2. Re:I'm tired of this closed source argument by Sancho · · Score: 1

      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!

    3. Re:I'm tired of this closed source argument by Anonymous Coward · · Score: 1

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

    4. Re:I'm tired of this closed source argument by Nicolay77 · · Score: 1

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

      --
      We are Turing O-Machines. The Oracle is out there.
    5. Re:I'm tired of this closed source argument by palegray.net · · Score: 1

      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.

    6. Re:I'm tired of this closed source argument by Herby+Sagues · · Score: 1

      That was a good one!

    7. Re:I'm tired of this closed source argument by microbee · · Score: 1

      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.

  11. I currently have by Colin+Smith · · Score: 1

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

    Does that make me a bad person?

    --
    Deleted
    1. Re:I currently have by tcopeland · · Score: 1

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

  12. No one should be surprised by Thelasko · · Score: 1

    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.

    --
    One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
    1. Re:No one should be surprised by Anonymous Coward · · Score: 0

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

    2. Re:No one should be surprised by rdradar · · Score: 1

      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 also detects if running inside vmware

    3. Re:No one should be surprised by Thelasko · · Score: 1

      Thanks for the info!

      --
      One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
    4. Re:No one should be surprised by InsaneGeek · · Score: 1

      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

  13. Not as vulnerable as you might think. by DavidKlemke · · Score: 1

    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).
    1. Re:Not as vulnerable as you might think. by argent · · Score: 1

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

  14. Companies rely on ESX, not desktop virtualization by ajquirk · · Score: 1

    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.

  15. Parallels Desktop has a similar problem... by argent · · Score: 4, Interesting

    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.

  16. ESX unaffected from this exploit by cyberblob · · Score: 1

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

  17. Obligatory XKCD by BrianGKUAC · · Score: 1

    So this might not be so safe after all?

    --
    Menus: Linux=function, Windows=vendor, OS X=as little as possible. Makes a statement, don't you think?
  18. Sounds like.. by Anonymous Coward · · Score: 0

    Sherlock Holmes has escaped the Holo-deck!!!

  19. On by default? by Aurthur · · Score: 1
    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.
  20. No Problem For Me by Zordak · · Score: 3, Funny

    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.
  21. Does this really impact many people? by 93+Escort+Wagon · · Score: 1

    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.

    --
    #DeleteChrome
  22. More virtualization is the answer by Ed+Avis · · Score: 2, Funny

    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
  23. Anyone notice how Linux hosts aren't vulnerable? by Schraegstrichpunkt · · Score: 1

    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.

  24. Update: Microsoft is irresponsible, as usual by Schraegstrichpunkt · · Score: 1

    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.

  25. a 100% secure OS like OS 10 by spazdor · · Score: 1

    lol.

    --
    DRM: Terminator crops for your mind!
  26. Short Short version by CokeJunky · · Score: 1

    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.

    --
    More Caffeine. NOW
  27. ::sigh:: by cyberfr0g · · Score: 0

    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.

  28. WINDOWS ONLY by awpoopy · · Score: 1

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

    --
    I say things which affects my Karma negatively. (and I don't care) For instance; All religion is false.