And if VMware file sharing is disabled...?

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.

No security expert worth their salt

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!

More and more VMware security bugs

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.

What VERSION of VMware Workstation?

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.

Is it just me..?

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

@Anonymous Coward

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.

Back to the future...

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

"Core's CTO Ivan Arce"

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

A month of....

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

It's true!

He really is called Ivan Arce. Look!

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

Best ever Register story

Is Privilege Escalation Involved?

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