Overview
On May 13, 2015, security researcher Jason Geffner of CrowdStrike publicly disclosed a vulnerability in some virtualization platforms that could allow an attacker to jump out of the sandbox of a virtual machine (VM) and gain access to the protected virtualization host. The vulnerability has been christened “VENOM”, for Virtualized Environment Neglected Operations Manipulation (CVE-2015-345) and affects any unpatched virtualization host built on the open source QEMU emulator, including Xen, KVM, and Oracle’s VirtualBox. Technologies that don’t employ QEMU, such as VMWare, Microsoft’s Hyper-V, and Bochs, are unaffected.
Virtualization Primer
Virtualization, in broad terms, is a technology implementation which allows one large computer to subdivide its resources (processor, memory, hard drive space, e.g.) to run many smaller, virtual computers. Each of these VMs runs as though it is a discrete system, isolated from the other VMs running on the same host. This architecture allows server operators to more easily manage and deploy servers, since they can create a new VM in much less time than it would take to build out a physical version. It also allows data center operators and hosting providers to make more efficient use of their resources. A virtualization host running, for example, 10 VMs uses a fraction of the space, power, and cooling that 10 equivalent physical machines use.
What Can an Exploit Against VENOM Do?
One of the other benefits of a virtualization platform is the ability to segregate VMs. So, even though they may use the same shared hardware, the VMs are isolated. Such isolation allows a server administrator to provision different VMs, running different operating systems, for different customers. Those customers would never know that they were sharing resources on a virtualization host with other customers. And even if they had root or administrator privileges on their VMs, the containment prevents them from doing anything that would affect any other VM.
This siloed infrastructure concept is what makes the idea of a vulnerability like VENOM so concerning. As Geffner describes on the CrowdStrike website:
This vulnerability may allow an attacker to escape from the confines of an affected virtual machine (VM) guest and potentially obtain code-execution access to the host. Absent mitigation, this VM escape could open access to the host system and all other VMs running on that host, potentially giving adversaries significant elevated access to the host’s local network and adjacent systems.
For a provider who has relied on the security of VM isolation, such a vulnerability can cause quite a bit of alarm.
How Much Alarm?
While the announcement of this vulnerability has been compared, in some media outlets, to Heartbleed, it’s important to weigh what is known against what is possible and probable.
According to Geffner, the “VENOM vulnerability has existed since 2004”, though no known exploit (as of this writing) has been documented in the wild. Geffner shared his findings with the major virtualization vendors who utilize QEMU on April 20, 2015. Once a patch was developed, he published his findings on the CrowdStrike website on May 13, 2015.
To date, though, there has been no public proof of concept demonstrated. We don’t currently know how simple or difficult it is to craft code that can exploit VENOM. Since VENOM leaves a system open to attack via the hacker’s old friend, the buffer overflow, it could, at its simplest, be exploited to cause the host machine to crash, resulting in a denial of service. With more care and cleverness, an attacker could potentially gain access to the virtualization host itself and be able to compromise the other VMs running on that same host.
What Can We Do To Protect Ourselves?
Since VENOM was disclosed responsibly, giving the vendors time to produce a patch, it’s incumbent upon virtualization host administrators to apply the patch as quickly as they are able. Individuals whose services run on VMs running on a shared virtualization platform can do little on their own. They can, however, visit their provider’s website to see if they are vulnerable and what steps are being taken to address the vulnerability. If necessary, they can apply pressure to push their administrators to patch their systems before this potential threat becomes a functional exploit in wide use by the darker side of the Internet.
To follow more about what Atlantic.Net is doing to address the VENOM vulnerability, check out our blog for the latest. We constantly strive to offer the most secure Virtual Private Servers offering the very best in one-click install applications like cPanel Hosting, among others.
Updated May 15, 2015, to include Atlantic.Net blog link
