
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 potential damage from their operation increases many times over. In this article I would like to talk about one of the main "new" threats in the virtual environment - the vulnerability of the hypervisor.
Consider the main classes of vulnerabilities of hypervisors on the example of VMware vSphere and possible ways to protect them from exploitation.
Buffer overflow and arbitrary code call
Certain errors in the hypervisor can cause a buffer overflow and trigger the launch of an arbitrary code. Errors can be contained both on the side of management of the virtual infrastructure, when their operation is conducted outside, with or without administrator rights, or from the side of virtual machines. In the second case, it is possible to go beyond the limits of 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 the processing of RPC commands, with the exploitation of the vulnerability, overflow is possible memory and the execution of arbitrary code 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 the launch of arbitrary code or a denial of service.
')
CVE-2013-1405 - A remote user can send a specially crafted authorization packet to ESX 3.5-4.1, ESXi 3.5-5.0 and vSphere Server 4.0-4.1, which will cause a buffer overflow and the launch of arbitrary code.
CVE-2012-2448 - A remote user can send a specially crafted NFS packet 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.
Protected against virtual infrastructure management will help impose virtualization protection, which filter all traffic going to the hypervisor.
It is more difficult to protect oneself from such errors from virtual machines with the help of imposed tools, but the consequences of an attack can be leveled out, for example, using the configuration integrity control mechanism.
Enhance user rights inside a virtual machine

A whole class of hypervisor vulnerabilities can disrupt the work of the guest operating system of the virtual machine and enhance the user's rights in it. In an ESX / ESXi environment, such attacks are usually implemented through two main areas - exploitation of vulnerabilities in VMware Tools (a set of utilities and driver for the guest operating system) or through direct access to the virtual machine memory through the hypervisor, bypassing the guest operating system access mechanisms.
Consider the examples:
CVE-2012-1666 - VMware Tools vulnerability in ESX 4.0-5.0 allows increasing access rights to the user of the guest operating system inside it by infecting with the malicious code of the tpfc.dll file.
CVE-2012-1518 is an ESXi 3.5-5.0 and ESX 3.5-4.1 vulnerability that allows increasing access rights to the user of the guest operating system inside it by using a 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 refraining from installing VMware Tools and using classical 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 dangerous in terms of compromise information class of vulnerabilities, but such vulnerabilities affect another indicator - availability. And their implementation has a negative impact on the quality of services of the cloud provider, the reputation of the service and, ultimately, on profits. We are talking about errors hypervisor, using which an attacker can lead to a denial of service, without spending much effort. Denial of service by generating a large amount of garbage traffic is not considered as a hypervisor-specific threat. We are talking about vulnerabilities in which one or more simple network packets or commands lead to the shutdown of the hypervisor in its entirety or its individual services.
As in the case of memory overflow, these errors can be contained in the external interfaces and internal functions of the 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 API for external services (vSphere API) in ESXi 4.1 and ESXi 4.1 contains an error that can cause a crash and a denial of service to the service accepting API requests if the RetrieveProp and RetrievePropEx commands are sent incorrectly.
Protection against attacks from external users is similar to protection against buffer overflow, when applied virtualization protection measures that filter all traffic going to the hypervisor.
Virtual machines do not yet have universal security solutions.
Conclusion
There is also a universal way to protect against known attacks, for example, applying security updates (“patches”) of the manufacturer itself and updating software versions to the latest.
However, this protection has two drawbacks. First, there are a large number of vulnerabilities, known only to a narrow circle of intruders, but so far unknown to the manufacturer and, accordingly, unaccounted for by him. Secondly, when using the certified FSTEK hypervisor, its updates are prohibited because they violate the integrity of binary files.
Therefore, it is recommended to use certified superimposed security features of the virtual infrastructure and, if possible, use the latest version of the non-certified hypervisor with the latest security updates. Only this method allows you to neutralize the threat associated with the presence of vulnerabilities in the software hypervisor.