Too many times, virtualization and cloud security folks hear that VM Escape is the main worry of security teams. This is far harder to do than most people realize, and requires the attacker to bust through multiple layers of defense in depth! If security teams are worried about VM Escape, then they really do not trust their own defense in depth. They may not even be able to articulate their defense in depth. They may even be confusing VM Escape with Admin Escape. They may just be using this to produce FUD so that they can say no to change. Well, the latter never works. We need to get over this obsession with VM Escape.
First, let us look at hypervisors. I know many of you know this already, but there is a distinct difference between VirtualBox and Xen or KVM as well as between VMware Workstation or Fusion and VMware vSphere. The major difference is that VirtualBox, Workstation, and Fusion run within another operating system, and Xen, KVM, vSphere, and Hyper-V do not. Actually, the later run within their own kernels specifically designed to eliminate VM Escapes wherever possible. Do not consider these entities the same. Do some research. If you hear about an escape, find out how was it done, on what platform. Is that a platform you use?
Secondly, how does one do a VM Escape? There is no magic. One VM cannot talk to another over anything but standard network protocols. A VM Escape implies one has not just jumped between VMs but has written and executed arbitrary code deep within the CPUs controlled by more than one VM. This implies you need to manipulate the hypervisor directly. There is the perception of VM Escape, and the reality.
The perception is that you can just hop from one VM to another without doing anything too strenuous. The reality of a VM Escape is very different than the perception. The following steps need to happen before an escape occurs:
- One must hack the VM in some fashion.
- One must hack administrator on the VM in some fashion without crashing the VM.
- One must hack from the VM to the virtual machine manager (VMM), which is often a large sandbox for running the VM. Once in the VM, one needs to hook onto something that is unknown (there is no shell here). It is in effect a no-man’s land. This is where one would normally try to execute arbitrary instructions that do not crash the VM.
- One must hack from the VMM to or through the hypervisor.
- One must hack the CPU or hack through the CPU. In order to jump between VMs, one often has to jump between CPUs.
- To jump between CPUs, one must hack the hardware system manager, which protects itself. One wrong move here, and one’s hardware will fry itself via the thermal protections in place.
- One must then somehow hack the target VM once more to run arbitrary code on the target VM.
It is far easier for an attacker to perform steps 1 and 2 above than to perform steps 3 through 7. As such, the counter to a VM Escape is to properly control access to virtual machines, management tools, and administrative users, regardless of where they live: in the cloud, in the data center, or even within a SaaS. Defense in depth is the only defense you need worry about when thinking about VM Escape.
In fact, an Admin Escape is far easier than a VM Escape. An Admin Escape is when the administrative user of the VMs or the management tools has been breached. If you breach the administrative users of the cloud management tools, then a VM Escape is not needed. You have effective access to everything: virtual disks, networks, even memory in some cases. This is why the lowest hanging fruit is to protect the admin. An Admin Escape takes one step:
- One must hack the administrator of the management component of the environment. In vSphere, that would be vCenter, in Xen it would be XenCenter, in KVM it would be libvirt or oVirt, and for Hyper-V it would be System Center.
However, many companies allow anyone to access these management tools. They allow any network to access those tools, and they allow any device. This is the problem, not VM Escape. To perform a VM Escape, I need admin access to the VM. In many cases, admin access to a VM gives you the credentials you need to gain admin access to the management tools. How do you ensure that the proper people have that access, that they are not good electronic copies of administrators? How do you control admins? Monitor them? Use different passwords, usernames, etc. for the different types of admins?
A host of defense in depth is required. It all starts with some form of Management Access Security Broker (MASB), which is a management-specific form of a Cloud Access Security Broker (CASB). A MASB tied to good authentication and authorization practices is the core to a good security posture for your entire hybrid cloud. One MASB is HyTrust, for vSphere environments. It is worth checking out. Controlling the admin limits any attempt at a VM Escape. Check out vmescape.com for a growing list of resources to read about why this is just not a big deal compared to Admin Escape.
Remember, to escape a VM in reality, one must first hack the admin (whether for the VM or for the management of a cluster of virtualization or cloud hosts). If someone is asking about VM Escape first, or even in their top five questions, they are really asking the wrong question, which shows they have fallen prey to the FUD.
Share this Article:
Latest posts by Edward Haletky (see all)
- Scale and Engineering - March 23, 2017
- SDS and Docker: The Beginnings of a Beautiful Friendship - March 21, 2017
- Security Operations Center: Not Just Visibility - March 14, 2017