on solving business problems instead of the minutiae of providing a substrate on which those products and services run. As a consequence of this shift in focus, it can sometimes be easy to overlook potential issues that occur at the lower levels of the application stack.
For example, over the past 16 to 24 months, a number of virtual machine (VM) escape issues have occurred of which customers might not be aware, including VMware SVGA driver issues (CVE-2017-4903), Hyper-V issues (CVE-2017-0109) and, in particular, a number of VM escape issues in the Xen hypervisor. Xen has had a number of issues related to paravirtualization in the past few years, such as CVE-2016-7092, CVE-2017-8903, CVE-2017-8904 and CVE-2017-8905, most recently.
What this means in practice is that, regardless of the hypervisor product you or your cloud provider employs, chances are pretty good that a potential VM escape issue has occurred that impacts your internal virtualization infrastructure or a cloud environment you employ — and potentially more than one. This matters because, even though the issue itself impacts a lower level of the stack than the customer has direct control over, the potential risk and impacts can propagate all the way up to your application, your data or the business logic upon which processes in your organization depend.
This means that, to ensure that an organization’s cloud security posture is as robust as possible, security practitioners should account for VM escape issues in their overall threat model. This is not often the mindset that practitioners have, as they often assume that attacks against the virtualization segmentation model are impossible — or so infrequent as to not warrant active consideration.
In recent years, VM escape vulnerabilities, though still rare, have occurred. While practitioners can’t always control what goes on under the hood in their cloud providers’ environments, they can take steps to help minimize the potential impacts if they consider the possibility of a VM escape at the outset.