Is it enough to exploit the vulnerability in a program? Is root or kernel access required? Are there maybe even possibilities to directly exploit the host without any vulnerabilities in the guest? To what extent does it depend on the hypervisor?

  • 3
    Seeing that it is the hypervisor's controls that you need to breach. it depends entirely on the hypervisor.
    – schroeder
    Jul 9 '18 at 14:37
  • KVM, Xen or VirtualBox would be my choice. Does it really depend so much on the hypervisor what kind of access you need to break out of the VM?
    – hurdar
    Jul 9 '18 at 17:22
  • 2
    Because it depends on the vulnerability you are exploiting ...
    – schroeder
    Jul 9 '18 at 17:31
  • Ok, I ask another way. Are you aware of exploits on the host without exploiting a vulnerability in the VM? From the know cases where someones was able to break out of a VM, was it enough to have a user level exploit for instance in the browser or was root or even kernel access required?
    – hurdar
    Jul 9 '18 at 17:44

Hypervisors are designed to protect against malicious guests, but bugs exist.

A hypervisor works by emulating certain hardware components so hardware drivers in the guest can communicate with them correctly. It also sets up hardware accelerated virtualization of the CPU and memory. I explain a bit about x86 virtualization and how it works in another answer. In general, exploiting a hypervisor will require either exploiting a bug in the emulation code of the hypervisor (code which either emulates trapped instructions or hardware devices), or the underlying hardware virtualization technology provided by the CPU itself. Different hypervisors merely provide different ways to interact with the hardware-provided virtualization. Xen, KVM, VirtualBox, HyperV, etc. are all high-level interfaces to the same primitive VT-x (for Intel hardware), which provides a set of CPU instructions for managing virtualization context (entering and leaving VMs, for example).

Is it enough to exploit the vulnerability in a program?

You need to be able to execute arbitrary code in the guest. One way to do that would be exploit a vulnerability in a program, for example exploiting a web server that is running on the guest.

Is root or kernel access required?

Sometimes, but not always. Root itself is just a regular user running in usermode. The only thing that makes it powerful is the fact that the kernel trusts it, allowing a root user to compromise the kernel. Once the kernel is compromised, malicious code can run at the highest privilege level. Many hypervisor exploits require messing with the virtual hardware in a way that can only be done in kernelmode, but not all vulnerabilities are like that. Some can be exploited by unprivileged code running entirely in usermode. In general, kernelmode allows for more in-depth interaction with the underlying hypervisor, greatly expanding on attack surface area.

Are there maybe even possibilities to directly exploit the host without any vulnerabilities in the guest?

Assuming the attacker has local unprivileged access to the guest, they may be able to attack the host over the network, if the host is listening on the network. This really depends on your setup.

To what extent does it depend on the hypervisor?

Heavily. The vast majority of VM escapes rely on vulnerabilities in the hypervisor. An exploit against Xen won't work on KVM. An exploit against KVM won't work on HyperV. Etc. While there are certain vulnerabilities that apply to all hypervisors by exploiting the underlying hardware accelerated virtualization technology (e.g. VT-x), these are far less common and tend to be much more conditional. An example is an IOMMU bypass on Intel VT-d1 where Interrupt Remapping and x2apic are not supported. This vulnerability allows disabling IOMMU restrictions, regardless of hypervisor.

  • Do you have some examples where unpriviledged code was enough to break out of the VM?
    – hurdar
    Jul 10 '18 at 6:20
  • I don't have any on me right now. I would imagine you could easily find one by looking at the CVE list for something like QEMU or VirtualBox.
    – forest
    Jul 10 '18 at 21:33

Is it enough to exploit the vulnerability in a program?

It depends on what your definition of enough is. I personally wouldn't want anything exploited at all. However, if your question is, is that all an attacker needs to start causing problems, then the answer is yes.

Is root or kernel access required?

Once again, this depends on what your attitude is toward security. I think any access is too much. Obviously root would be way worse.

Are there maybe even possibilities to directly exploit the host without any vulnerabilities in the guest?

Let's assume for a second that your virtual machine is public facing since you're asking about someone that's gotten a shell into it. Now this person is inside your network. Regardless if they have root or not on that box, they can possibly see other machines behind your firewall. They can very likely load tools onto your vm and use said tools to start probing other machines on your network.

You know whom else is on your network? Your host machine.

You don't need exploits to break out of a VM if it's public facing and on your network.

Now I made a lot of assumptions in this answer because you didn't really provide a ton of info on your setup.

The main assumptions I made are that you have a VM with bridged access to your network and it's exposed to attackers.

Final thoughts on this

When I setup vulnerable VMs on my network to practice on, they're inside VMs. I often will setup multiple VMs and move between them. Sometimes I even run my attacking machine in a VM but often I'll come at it from my laptop as if I just joined the network. The VM's look identical to any other machine on my network even though they're all on the same box. Just because something is a virtual machine doesn't mean it's sandboxed.

  • Networking would certainly be an option. Maybe even the most convenient one. I'm not sure how the average cloud provider does it but at least my host never has direct internet access or even an IP address. I actually opened another question which goes a bit in this direction. Could you come up with other possibilities without network access? As a sidenote I'd love to hear about your setup. Maybe you already have a blogpost on this? I also run nested VM's for testing but the speed is ... . Sandboxing VMs is another concern. How do you sandbox your VMs?
    – hurdar
    Jul 9 '18 at 17:37
  • @hurdar my setup doesn't go much deeper than what I described. I've been wanting to build a pentest lab at home but I'm terrified of leaving vulnerable machines up and running 24/7. I'm in no way a networking expert. I know I'd leave holes. I usually just spin them up when I want to practice. Then I kill or pause them Jul 9 '18 at 17:57

To break the hypervisor sand boxing you need something from the hypervisor. Breaking the app or elevating your privileges to root inside the guest OS might help you if you need those privileges to interact with guest kernel. Depends on the hardening.

Some bugs in the past would allow escaping the hypervisor sandbox, normally this is related with instruction calls or with vulnerabilities in the drivers like the vga or usb emulators or any other layer that the hypervisor is providing to the guest to allow resource usage.

This is an example showed last year, they escaped EXI guest OS and become root at the hypervisor.



They used a virtual network adapter bug to achieve success.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.