1

Problem

So I set up a virtual backtrack machine using VMware Workstation - I'm trying to launch an attack against the host OS (Ubuntu Linux) from the virtualized host (backtrack), but I do not understand what questions I need to research to find information regarding the methodology for this.

If anyone could point me in the direction of a resource, blog, book, or simply explain a high-level methodology for how one would approach breaking out of a virtual machine, I would greatly appreciate it.

Thanks,

Andrew

PS: Like, how does access control and privilege work across a VM? Is it like a process broker sandbox?...

gal
  • 649
  • 2
  • 6
  • 12
  • Please include what research you have already done on your own (if any) and links to the papers you've read on this topic. You might also want to check any relevant topics on IT.sec, such as [Does a Virtual Machine stop malware from doing harm?](http://security.stackexchange.com/questions/9011/does-a-virtual-machine-stop-malware-from-doing-harm) and [How secure are virtual machines really? False sense of security?](http://security.stackexchange.com/questions/3056/how-secure-are-virtual-machines-really-false-sense-of-security) and see if those answer your question or help you form it. – TildalWave Feb 02 '13 at 19:33

1 Answers1

5

A virtual machine is an isolation layer. The code which runs into the VM (the "guest") is not supposed to be able to escape the VM and reach the host, except through the access facilities which have been explicitly enabled by the VM (e.g. networking).

Therefore, to break out of the VM, you need to find and exploit a security hole in the VM implementation -- VMWare Workstation in your case. Methodology would then be: search the Web for a description of known vulnerabilities. For instance, a simple Google search links to this.

The VM emulates a virtual machine: the guest kernel and the host operating system live in completely distinct worlds. Or, more accurately, the VM is a single process from the point of view of the host; the guest runs on hardware which does not exist, and maintains its own forest of internal process. Nowadays, VM managers are hypervisors; they use dedicated CPU opcodes to "remain hidden" from the guest: whatever the guest tries to do, it does so through some code which runs on the CPU, and the hypervisor intercepts the opcodes which could "see through the veil". This movie is a big metaphor on the hypervisor / virtual machine relationship, and it explains the situation quite well -- if you get past the heavy weapon handling and the spunky females in tight clothes, that is.

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • Thanks! This was a big help =) I appreciate the concise answer and the feedback =D – gal Feb 02 '13 at 19:37
  • 2
    +1 and LOL at The Matrix reference :) @Andrew - If Tom provided you with all you wanted to know and his post answers your question, then please consider accepting it. ;) – TildalWave Feb 02 '13 at 20:03