Hypervisor Vulnerabilities - Threat to Virtual Infrastructure and the Cloud

When moving from a physical infrastructure to a virtual one, many new threats arise. With the expansion of virtualization to the cloud, their list expands, and the possible damage from their operation increases many times. In this article, I would like to talk about one of the main "new" threats in the virtual environment - hypervisor vulnerabilities.
Let's consider the main classes of vulnerabilities of hypervisors using VMware vSphere as an example and possible ways to protect against their exploitation.

Buffer overflow and arbitrary code invocation

Certain errors in the hypervisor can cause buffer overflows and trigger arbitrary code execution. Errors can be contained either on the side of the virtual infrastructure management when they are operated externally, with or without administrator rights, or on the side of virtual machines. In the second case, it is possible to go outside the virtual machine and execute any commands on the hypervisor.

Examples of known vulnerabilities:

CVE-2012-1516 ... 1517, CVE-2012-2448 ... 2450 - The VMX process in ESXi 4.0-5.0 and ESX 3.5-4.1 is vulnerable due to an error in processing RPC commands, exploitation of the vulnerability could lead to overflow memory and arbitrary code execution on the host operating system from guest operating systems.

CVE-2013-3657 - A remote user can send a specially crafted packet to ESX 4.0-4.1 and ESXi 4.0-5.0 and cause a buffer overflow with arbitrary code execution or denial of service.

CVE-2013-1405 - A remote user can send a specially crafted authorization package to ESX 3.5-4.1, ESXi 3.5-5.0 and vSphere Server 4.0-4.1, which will cause buffer overflows and arbitrary code execution.

CVE-2012-2448- A remote user can send a specially crafted NFS package to ESX 3.5-4.1 and ESXi 3.5-5.0 and cause a buffer overflow with the launch of arbitrary code or denial of service.

The virtualization protection tools that help filter all traffic to the hypervisor will help protect against attacks from the side of virtual infrastructure management.
It is more difficult to protect oneself from such errors on the part of virtual machines by means of superimposed means, but the consequences of an attack can be leveled, for example, using the configuration integrity control mechanism.

User elevation inside a virtual machine

A whole class of hypervisor vulnerabilities can disrupt the guest operating system of a virtual machine and increase user rights in it. In the ESX / ESXi environment, such attacks are usually carried out in two main directions - exploiting vulnerabilities in VMware Tools (a set of utilities and a driver for the guest operating system) or through direct access to the virtual machine's memory through the hypervisor bypassing the guest operating system access mechanisms.

Consider the following examples:

CVE-2012-1666 - VMware Tools vulnerability in ESX 4.0-5.0 allows to increase access rights for a user of a guest operating system inside it by means of tpfc.dll file malware infection.

CVE-2012-1518 is a vulnerability of ESXi 3.5-5.0 and ESX 3.5-4.1, which allows increasing the access rights of a guest operating system user inside it by using buffer overflow in VMware Tools if the access rights for the directory with VMware Tools are configured incorrectly.

You can protect yourself from this class of vulnerabilities by refusing to install VMware Tools and using the classic means of protecting information from unauthorized access inside the guest operating system, similar to a physical computer.

Denial of service

At the end of the list is the least vulnerable class of vulnerabilities in terms of compromising information, but such vulnerabilities affect another indicator - accessibility. And their implementation negatively affects the quality of the cloud provider’s services, the reputation of the service, and, ultimately, the profit. We are talking about hypervisor errors, using which an attacker can lead to a denial of service without spending a lot of effort. Denial of service by generating a large amount of junk traffic is not considered a hypervisor-specific threat. We are talking about vulnerabilities in which one or more simple network packets or commands cause the entire hypervisor or its individual services to stop working.
As in the case of memory overflow, these errors can be contained both in external interfaces and in the internal functions of virtual machines.

Examples of such vulnerabilities:

CVE-2013-5970 - the hostd-vmdb service in ESXi 4.0-4.1 and ESXi 4.0-5.0 can be disabled by sending a specially prepared network packet.

CVE-2012-5703 - The External Services API (vSphere API) in ESXi 4.1 and ESXi 4.1 contain an error that could cause the service accepting API requests to crash and fail if the RetrieveProp and RetrievePropEx command parameters are incorrect.

Protection against attacks from external users is similar to protection against buffer overflows when virtualization protection tools are applied that filter all traffic going to the hypervisor.
From the side of virtual machines, universal protection solutions do not exist yet.

Conclusion

There is also a universal way of protection against known attacks, for example, applying security updates (“patches”) of the manufacturer itself and updating software versions to the latest.
However, such protection has two drawbacks. Firstly, there are a large number of vulnerabilities that are known only to a narrow circle of attackers, but so far unknown to the manufacturer and, accordingly, unaccounted for by it. Secondly, when using the FSTEC certified hypervisor, its updates are prohibited, as they violate the integrity of binary files.
Therefore, it is recommended to use certified overlay protection tools for the virtual infrastructure and, if possible, use the non-certified latest version hypervisor with the latest security updates. Only this method allows you to neutralize the threat associated with the presence of vulnerabilities in the software of the hypervisor.