What kind of access on the guest is required to break out of a virtual machine?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

https://twitter.com/ChaitinTech/status/1057526019127676929

https://www.vmware.com/security/advisories/VMSA-2018-0027.html?ClickID=czxwsa74s4leafwfzvzkzq7a4f4xqlaklzax

They used a virtual network adapter bug to achieve success.