Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security

Critical VMware Vulnerability, Exploit Released 104

Posted by kdawson from the heads-up-incoming dept.
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."
This discussion has been archived. No new comments can be posted.

Critical VMware Vulnerability, Exploit Released More

Critical VMware Vulnerability, Exploit Released

Comments Filter:

  • Limited issue (Score:3, Interesting)

    by nhtshot ( 198470 ) on Thursday February 28, 2008 @02:45PM (#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 (Score:5, Insightful)

      by Brian Gordon ( 987471 ) on Thursday February 28, 2008 @03:46PM (#22592652)
      Anyone using Shared Folders is just asking for trouble anyway.. any sort of production setup will have a proper virtual network.

      • Re: (Score:2)

        by nurb432 ( 527695 )
        That was my first thought as well, would have to be an amateur running the show.

      • Re: (Score:2)

        by TopSpin ( 753 ) *

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

        • Re: (Score:2, Interesting)

          by billcopc ( 196330 )
          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

        • Re: (Score:1)

          by Jeruvy ( 1045694 ) *
          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
    • 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? (Score:5, Insightful)

    by Mostly a lurker ( 634878 ) on Thursday February 28, 2008 @02:46PM (#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? (Score:5, Informative)

      by sammy baby ( 14909 ) on Thursday February 28, 2008 @02:56PM (#22592084) Journal
      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? (Score:5, Informative)

        by sammy baby ( 14909 ) on Thursday February 28, 2008 @03:01PM (#22592176) Journal
        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: (Score:3, Informative)

          by Amouth ( 879122 )
          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: (Score:2, Informative)

            by Grakun ( 706100 )
            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: (Score:2)

              by Amouth ( 879122 )
              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: (Score:2)

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

      • Re: (Score:1, Troll)

        by TopSpin ( 753 ) *

        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

    • Re: (Score:2)

      by 0racle ( 667029 )
      It's more transparent to the user, there's no setup. Personally I just use standard networking.

    • Re: (Score:3, Informative)

      by milsoRgen ( 1016505 )

      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: (Score:2)

      by grcumb ( 781340 )

      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.

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

    • 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 softw

    • Re: (Score:1)

      by Lavene ( 1025400 )

      ... 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! (Score:5, Informative)

    by NNKK ( 218503 ) on Thursday February 28, 2008 @02:48PM (#22591978) Homepage
    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.
    • 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: (Score:3, Informative)

        by Anonymous Coward
        VMPlayer Does support shared folder, you just have to edit the .vmx file yourself...
  • I always use SSH as transfer between the host and guest environment, yes it is slower but so much saver.

    • Re: (Score:3, Insightful)

      by dominux ( 731134 )
      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: (Score:2)

        by Sancho ( 17056 )
        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
        • 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: (Score:2)

            by Sancho ( 17056 )
            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... (Score:5, Informative)

              by BestNicksRTaken ( 582194 ) on Thursday February 28, 2008 @05:26PM (#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: (Score:2)

                by Sancho ( 17056 )
                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: (Score:1)

      by entmike ( 469980 )
      I don't see the point of this at all.

  • Doesnt affect Server (Score:2, Interesting)

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

    • Re: (Score:2)

      by argent ( 18001 )
      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: (Score:2)

      by 0racle ( 667029 )
      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.
  • 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? (Score:5, Interesting)

      by garett_spencley ( 193892 ) on Thursday February 28, 2008 @03:31PM (#22592510) Journal
      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: (Score:2)

      by Amouth ( 879122 )
      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 c

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

    by vux984 ( 928602 ) on Thursday February 28, 2008 @03:03PM (#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 (Score:5, Informative)

      by theotherbastard ( 939373 ) on Thursday February 28, 2008 @03:08PM (#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: (Score:3, Informative)

        by cnettel ( 836611 )
        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: (Score:3, Informative)

        by 0xABADC0DA ( 867955 )

        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 w

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

    Does that make me a bad person?
     
    • > 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...

  • 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.
    • 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
      • Thanks for the info!
      • 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

  • 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: (Score:2)

      by argent ( 18001 )
      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).
  • 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.
  • 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.
  • But for those of us using an ESX environment this is not a problem.
  • So this [xkcd.com] might not be so safe after all?
  • 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 (Score:4, Funny)

    by Zordak ( 123132 ) on Thursday February 28, 2008 @05:06PM (#22593644) Homepage Journal
    I'm always careful to run potentially vulnerable applications like this in a secure virtual environment.
  • 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.

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

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

  • 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

Slashdot Top Deals

GREAT MOMENTS IN HISTORY (#7): April 2, 1751 Issac Newton becomes discouraged when he falls up a flight of stairs.

Close