What is a virtual machine escape?
A virtual machine escape is an exploit in which an attacker runs code on a VM that lets the operating system (OS) running within it break out and interact directly with the hypervisor. By exploiting a vulnerability in the hypervisor’s code, guest OS or applications running on the VM, the attacker can directly interface with and compromise the underlying physical resources and VMs.
VMs are designed to run in self-contained, isolated environments in the host. Each VM should be, in effect, a separate system, isolated from the host OS and any other VMs running on the same machine.
The hypervisor, also known as a virtual machine monitor, is an intermediary between the host OS and VMs. It controls the host processor and allocates resources as required to each guest OS. If the system is working correctly, a guest OS wouldn’t “know” that it’s part of a VM. Rather, it “thinks” it has full access to the emulated — or virtual — machine that the hypervisor is providing.
A VM escape attack compromises these normal actions. By exploiting a vulnerability, the attacker can bypass the isolation and security controls the virtualization layer provides. The exploitation of the hypervisor is called a hypervisor-level VM escape attack. Another way to execute a VM escape attack is to exploit the vulnerabilities in the guest OS or VM applications. This is a guest-level attack.
Either way, a successful attack lets the attacker escape — hence the name — the isolation of a VM and then access and control the host OS and all the other VMs running on it. The attacker might also be able to access any sensitive information stored on the physical machine and even on the network to which it’s connected.
How a VM escape attack might occur
It’s rare to hear about VM escape incidents. Nonetheless, VM escape is still considered one of the most serious threats to VM security.
These attacks could result from misconfiguration errors or vulnerabilities in the virtualization software or hypervisor code. Attackers could also exploit vulnerabilities in the VM host’s OS. Software vulnerabilities that might be exploited include buffer overflows and code injections.
Apart from software exploitation, threat actors could manipulate the hypervisor’s interface to take advantage of its vulnerabilities. After breaching the virtualization layer’s isolation, they could trick the hypervisor into executing malicious code and, ultimately, perpetrate a VM escape attack that gives them access to and control over the host system.
Another way to execute a VM escape attack is to exploit the virtual hardware features in a virtualization platform. By exploiting features such as direct memory access or virtual device drivers, a hacker could breach the isolation and gain unauthorized access to the underlying host system.
Possible effects of a VM escape attack
A successful VM escape attack can give an attacker access to the hypervisor or host system. At that point, they can potentially infiltrate all the other VMs running on that host, compromise its resources or exfiltrate its sensitive data.
An attack can put the underlying infrastructure at risk by expanding the attack surface. This could allow the hacker to execute denial-of-service attacks or advanced persistent threats.
Any of these issues can disrupt critical operations, create service outages and lead to downtime in the virtualized environment, all of which can impair an organization’s ability to deliver its products or services. Investigating and mitigating a VM escape attack can be costly and harm the affected organization’s revenues, customer relationships and reputation.
VM escape attacks on Type 1 and Type 2 hypervisors
Both Type 1 and Type 2 hypervisors are used to run VMs on a single physical machine. The hypervisor’s job is to allocate physical resources to each VM and communicate with the physical machine’s underlying hardware to ensure an isolated computing environment is available to users.
The main difference between the hypervisors is in where they “sit.” A Type 1 hypervisor is known as a bare-metal hypervisor since it sits on top of the bare-metal server. It can directly access and interact with the underlying machine’s hardware resources instead of having to go through the OS. A Type 2 hypervisor, also known as a hosted hypervisor or embedded hypervisor, is installed on the host OS and interacts with the host hardware through this OS.
This difference is important because it is what makes it easier to perform VM escape attacks on a Type 2 hypervisor compared with a Type 1. With the Type 2 hypervisor, a hacker can potentially gain access to the underlying OS that’s hosting the VMs to escalate their privileges, circumvent the virtualization layer’s protection mechanisms and access the VMs hosted on that device. All this is harder to do, although not impossible, on a Type 1 hypervisor.
How to prevent VM escape attacks
Ongoing vigilance over the virtualization environment is critical to prevent VM escape attacks. It’s also important to properly configure and harden all VMs and to ensure the guest OS, host OS and hypervisor are regularly patched and always kept up to date.
Here are additional strategies to minimize vulnerability to VM escape:
- Install only the resource-sharing features that are required.
- Minimize software installations to reduce the chances that an exploitable vulnerability is introduced.
- Ensure all VMs are isolated from each other and from the host OS.
- Restrict network access on a need-to-have basis and carefully monitor all network activity to detect suspicious activities and accelerate incident response.
- Install strong security controls on the host machine to minimize damage in case of a VM escape attack.
More hackers are using virtual machines as an access point to install and deploy encrypted ransomware. See how to secure your infrastructure against VM ransomware. Also, check out this virtualization security checklist.
