How to handle risks of hypervisor hacking

Global cloud computing and digital systems today would not exist without virtualization and hypervisors. Virtualization and hypervisors are basic tools for implementing digital systems that respond from moment to moment to varying demands without slow and expensive physical reconfiguration of hardware and rebuilding of software execution stacks and heavy investment in hardware that is only used during peak loads.

Last blog, I described the dangers of a hypervisor attack. How can such an attack occur? There are a number of ways.

Resource simulations

A hypervisor provides software simulations of basic computing resources — like CPUs, memory, storage and network connections — that isolate VMs from one another. But the isolation may have soft spots. For example, freed simulated memory for one VM might be the same physical memory the hypervisor allocates to another VM. If the hypervisor does not blank out the reallocated physical memory, the second VM has access to data from the first VM and a data breach ensues. All resource simulations are subject to dangerous implementation errors. Simulated CPU registers, storage buffers and network buffers, all present opportunities for coding mistakes that permit data or control breaches.

Hypervisor APIs

The APIs with which hypervisors communicate with VMs and the underlying physical resources are also vulnerable. For example, a call from a VM to the hypervisor that is not properly authenticated could masquerade as a call from a different VM, allowing access to unauthorized data or actions. The same applies to faulty drivers that interface between hypervisor and physical hardware.

VM management

VM management controls also present dangers. Depending on the hypervisor architecture, VM activity is regulated by a hypervisor control console or a specially empowered VM. These control facilities start, suspend or stop VMs. Most VMs can be ordered to write an image to a file that can be used to start a replica VM in the exact state when the image was made. If a hacker can gain unauthorized access to the control facility, they can stop, start and steal VMs at will, which is the virtual equivalent of an intruder running amok in a data center flipping switches and hauling off equipment.

Hypervisor add-ons

Most hypervisor systems include some facility for add-ons, optional features not available with the basic system. Rogue add-ons can maliciously open backdoors and other remote access portals, exfiltrate data, or other nefarious actions. Add-on mechanisms that are designed for third-party additions are often useful, but also more open to subversion.

VM images

VM users have to be cautious about securing VM images. One danger is unauthorized instantiation of a critical VM from a stolen image. Another subtler danger is that hackers may be able to analyze the image, which will contain a literal dump of memory contents. Ordinarily, developers assume that critical data like passwords held in memory is safe from prying eyes, but that is not the case when memory is dumped to an image on disk. Therefore, hackers may be able to extract information from VM images that developers think is safe.

Inter-process communication obscurity

A final caution is that a virtualized stack which contains several interacting processes, say an archetypal LAMP (Linux, Apache, MySQL, Perl/Python/PHP) stack, inter-process communication and file access is simulated within the hypervisor process. Consequently, these activities may be invisible to monitoring systems that are intended to detect anomalous malicious activity over the usual non-virtual interfaces.

How significant are these vulnerabilities? At this point, there are no realistic alternatives to virtualization and hypervisors for high levels of flexibility and high-speed reconfiguration. The vulnerabilities that I have described here are all defects, not inherent flaws in virtual architectures, although they are, to a certain extent, dangers that arise in any complex digital implementation.

Mitigation

How can the risks be reduced? First, hold virtualization implementers to high standards. We have learned a lot in the last few decades about development methodologies that reduce defects and quickly detect and remediate defects that make it through development and into production. When consistently practiced, DevOps, the methodology that removes the traditional boundaries between development, deployment, and production, and embraces continual improvement, has greatly increased system reliability. Hypervisor implementations have fared well. Although potential exploits have been found, the hypervisor developers have also been diligent about fixing problems. This has kept the number of actual malicious exploits low.

However, developers make mistakes and diligence is not absolute protection. Some flaws always creep in. Users must be aware of the vulnerability of the hypervisor layer. Insist that both internal and external service providers properly secure virtualization management facilities. Users of public clouds in particular, must be aware of the potential for VM cross-contamination and require providers to keep them off hypervisors with dodgy VM neighbors. Exercise caution with hypervisor add-ons. Install only add-ons certified from reputable sources. Users should secure images of critical VMs and not assume that conventional monitoring systems will be able to detect malicious activities in virtualized stacks.

Next

If you would like to dig deeper into hypervisor vulnerabilities, I suggest reading an excellent article. Although several years old, “Characterizing Hypervisor Vulnerabilities in Cloud Computing Servers” categorizes and describes vulnerabilities in XEN and KVM hypervisors. VMware and Microsoft Hyper-V are subject to similar issues, but they are somewhat harder to research because the code is proprietary. Nevertheless, the article is a good starting point for a deep divers.