One could always use VirtualBox instead of VMware.

http://www.virtualbox.org/

I am not connected with the project in any way.

If VMware file sharing is disabled, which of course sensible people would do when running untrusted (or worse) software as the guest OS, does this exploit still succeed? Hopefully not, though afaict the article doesn't say either way. Anyway if it does become safe, the article title maybe ought to be "VMware vuln exposes the perils of being dumb".

Paris isn't dumb but she may be vulnerable. Or is that the other way round, I forget.

Would share files from a sandbox to their host PC. Sad to see that VMware has this vulnerability though - hope to see it patched soon!

As a very large VMware who has invested more than a few quid in VMware products (both desktop and server), the bloody bloom is off the rose. VMware security bugs are commonplace and the quality of their products has taken a major downturn since VI3. Version 3.0 was released about six months too early and after some proper testing, 3.0.2 was released as an apology.

It's time to right the ship gents.

Is the Linux version of Workstation vulnerable to this bug? The bulletin from Core doesn't go into details on what OS version or what release version of VM Workstation is affected.

Or has no-one else notice Core's CTO's name? Best name ever or just stating the bleeding obvious?

If you read the end of the article, I think you will find your question answered...

@El Mono Grande: As with all security bugs, it is safe to assume that all versions up to and including the most recent one, for all OSs, are affected.

"method for dividing a PC's resources into separate environments that - in theory, at least - can't be altered by other environments."

According to that definition, ALL operating systems SHOULD count as VM hosts out-of-the-box. In theory, all processes should be completely isolated from all others, except for a select few carefully-defined comms channels, with effective access controls placed everywhere.

Of course, that's where reality raises its ugly head. But sloppy design, compromises in the name of performance, and backwards-compatibility with previous sloppy designs take their toll. User convenience causes the controls to be relaxed and the allowed channels to proliferate. And that's before we even start talking about actual bugs...

So now we implement virtual machines to restore the security that our OS's couldn't deliver. Except that our VMs suffer from user convenience demands, sloppy design, performance compromises, backwards compatibility, and bugs.

Let's just give it up and move back to the abacus...

Since VMware is just another piece of software, then bugs like this should be expected -- much like leaks discovered in Java's sandbox. If you can code something, chances are someone else can code around it, given enough time.

Thanks for the heads up. I misread it first time! Brilliant!

C'mon, _really_? That's gotta be an early April 1!

I'd start with VMWare tools - which supplies amongst other things a screen driver. Then there's the VNC back door, the sound card, the USB passthrough....

And he really really really is called that:

http://www.coresecurity.com/?module=ContentMod&action=item&id=47#ivan

seems ivan arce is just too much for people to ignore and they've followed the link killing core's website...

the reg effect!

http://www.pcpro.co.uk/news/171459/real-risk-for-vmware-users.html

Run your VMWare within a Virtual PC...

He really is called Ivan Arce. Look!

http://www.coresecurity.com/?module=ContentMod&action=item&id=47

Best ever Register story

Greetings,

As Morely Dotes noted you could use Virtual Box. Problem be it also has a shared folder function and is probably affected by this exploit.

The difference is it is not set up by default. Look in the user manual, section 4.4 for more info on enabling shared folders between host and guest.

Or be a little safer and leave it disabled when exploring malware.

As far as I can see from the linked article this is just a directory traversal issue. This means that the underlying OS is only as vulnerable as permitted by the account running the virtual machine - not an immediately pwned situation if you run the vm as a limited (i.e. non-admin) user.

If you run a vm without any security then you risk having your host disk read and broadcast on the internet (and incriminating evidence planted on it too.)