One could always use VirtualBox instead of VMware.
I am not connected with the project in any way.
Security researchers have discovered a bug in VMware desktop virtualization applications that allows attackers to take complete control of the underlying PC, including the execution or modification of files on the host operating system. The vulnerability, which was unearthed by researchers from Core Security Technologies, is …
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.
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.
"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...
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.)