Breaking down the risks of VM escapes

What is a VM escape attack?

For those who are unfamiliar with the vulnerability, it was described as a VM escape attack. This is a type of attack whereby an attacker "break outs" or escapes from the virtualized sandbox environment that segments individual virtual guest instances from the hypervisor on which they run.

In the case of a type 1 hypervisor like Xen, guest OS instances are allowed to run in a controlled sandbox-like environment, but are not allowed -- as a security precaution -- to make modifications to the hypervisor itself -- or, for that matter, to other instances that might be co-resident. Instead, they are purposely kept sequestered and segmented from each other. An escape attack allows an attacker to break that separation and gain unauthorized access to the hypervisor, using it as a stepping stone to move laterally throughout the network, or to compromise other co-resident guest images on the same device.

Nowadays, this type of issue is rare, but it's happened in the past; for example, CVE-2008-0923 in 2008 demonstrated a directory transversal attack in VMware's shared folders feature, which allowed an attacker inside the guest OS to gain access to files on the hypervisor outside of those specifically allowed by the administrator. On the whole, however, modern hypervisors are a mature technology. Meaning these segmentation mechanisms are robust, having had years of production presence in the marketplace to help find and remediate issues of this stripe. This is in part what makes the Xen issue surprising and notable.

Why this matters now

To the earlier point, one of the most thought-provoking aspects of this Xen hypervisor issue is the timing of it. It surfaces at a time when many companies are investigating or experimenting with application containers. What is an application container? It includes products like Docker and Rocket that allow the creation of "packages" containing an application as well as everything required (e.g., libraries, middleware, configuration settings and more) for that application to run.

The Xen hypervisor flaw serves as a timely reminder for the container world as well as for the OS virtualization world.

This concept has generated quite a bit of interest from enterprises because of the impact containers can have with developers and in the data center. Containers are portable and lightweight -- lighter than, for example, a virtual machine image. In addition, they have the potential to streamline development and make transitions between environments -- such as from developers to QA and from QA to production -- easier. And because they increase efficiency in the data center and remove the need to maintain banks of similarly configured virtual OS images, they can increase allocation density there as well.

The key to this process is segmentation. Specifically, applications are segmented from each other and from the underlying host, running in a "sandbox-like" environment in a much similar fashion to the way guest OS images are segmented from each other and the hypervisor in OS virtualization. The analogy of course isn't perfect -- containerization and OS virtualization are not the same thing. However, the similarities are enough that the Xen hypervisor issue serves as a reminder that escape vulnerabilities exist, can surface at any time, and security programs should account for the possibility of them emerging in containers.

While OS virtualization has had segmentation mechanisms that have had years to mature, application containers are earlier in the lifecycle. Specifically, while the concept of a virtual container has been around for a number of years, new tools that leverage the concept are still relatively new. Plus, there are several known situations where segmentation between containers was shown to be permeable. As a result, the Xen hypervisor flaw serves as a timely reminder for the container world, as well as for the OS virtualization world.

What can security professionals do about this situation? In many cases, thinking about an escape attack can provide a leg up in helping to defend against this type of situation. Meaning, it may not always be in our power to prevent an escape-type attack, but we can take action such that, should it occur, we are in a better situation than we would be otherwise. For example, security professionals should consider a defense-in-depth approach that layers multiple countermeasures in the event that one mechanism fails to stop an attack; alternatively, consider additional controls at the application layer over and above those you assume are operating lower down the stack. You might consider additional monitoring controls and data protection controls, such as encryption, to help locate an attack more quickly or decrease exposure should an attack occur.

An issue like the Xen hypervisor VM escape flaw may be rare, but it can serve as a powerful warning for potential risks. It's important for security managers to remember that forewarned can be forearmed. And a reminder like this one, timely as it is, can help make sure these issues are front of mind in security planning going forward.