It is possible to bypass Vmware, workstation or not, simply by writing to memory and then from memory executing code on the real desktop.
Vmware is connected to one's desktop, and this poses a real security threat. People like myself, who test malware on Vmware workstation, will find themselves in a real hazard of getting infected. Moreover, people who are familiar with the working of Vmware will know how to exploit it.
There's really no security in Vmware, and I'd like this to be different in the near future.
Are you hallucinating?
The guest OS cannot modify the host OS memory in any way, and if you disable all sharing features (shared folders, shared clipboard, etc.) the guest becomes a fully isolated environment.
Anyways, show us this vulnerability!
A compiled code will suffice.
We consider the isolation between a VM and its host to be critically important, and we've expended a lot of effort to achieve a very high level of isolation.
If you have any questions about the level of isolation you should expect from VMware products, or questions about how the configuration of your virtual machines can affect isolation, feel free to ask detailed questions here.
If you are aware of a specific vulnerability in a VMware product (for instance, if you can demonstrate a virtual machine compromising its host or manipulating its host in an unexpected way), you could provide a detailed report by following the instructions on our Security Response page and we'll investigate.
What kind of a question is that?
This topic has no relevance to modifying the OS which Vmware is run on. What I am talking about is getting actual access to the OS, which is an easy task. The supposed "guest" OS has as much access to hardware components as the OS which Vmware is run on.
If you have any idea how a computer works, you'd have sufficient knowledge to compute the simple fact that any malware can actually get access to the original OS simply by modyfying hardware components.
I am obviously not going to share any source codes - what benefit would there be in this?
You don't ask a robber who turned himself in, "Hey, we think you're lying! You need to demonstrate how you committed this robbery, or else we'll dismiss your case as fraud."
What I am talking about is getting actual access to the OS, which is an easy task. The supposed "guest" OS has as much access to hardware components as the OS which Vmware is run on.
We go to great lengths to ensure that the guest does not have unfettered access to the host hardware, and to ensure that the guest cannot directly map and access memory that doesn't belong to the virtual machine. Even in cases where guest code is running directly on the host's CPU, it is done under strictly controlled conditions to ensure that the virtual machine remains "sandboxed" from the host.
If you have found a case in which the guest OS can actually access memory that it doesn't own, I'd appreciate if you could let our security team know, and you can be assured that they will investigate thoroughly.