Breaking hypervisor isolation and attacking -- or exploiting -- neighbouring virtual machines is a prominent goal of cyber criminals. At the Black Hat USA 2015 and DEF CON 23 conferences, a group of Intel Security researchers from the Advanced Threat Research team demonstrated that some hypervisors are vulnerable to attacks through system firmware launched from administrative guests. These attacks led to successful installation of a rootkit in the system firmware (such as BIOS), privilege escalation to the hypervisor privileges, and exposure of hypervisor memory contents.
Hypervisors employ a range of techniques to isolate software and I/O devices, block escapes from any compromised virtual machine to any other virtual machine, and protect each virtual machine’s secrets from the others, including their operating systems. However, these protections fall short when the physical machine system firmware is infected with a rootkit or when a compromised virtual machine is able to exploit vulnerabilities in the firmware.
In this case, the firmware rootkit was installed by reflashing the system firmware while it wasn’t adequately protected in non-volatile flash memory. Physical access controls should prevent this in some cases. However, the research also demonstrated that the rootkit could be installed from within privileged guests on the machines with inadequately write protected firmware. Our research demonstrated that a rootkit can open a backdoor for an attacker to access the memory contents of all other virtual machines by adding entries to the hardware-assisted page tables and mapping all of DRAM to the attacker’s guest address space. The attacker can then access the active memory of all the other virtual machines on this host and harvest data at will.
Solutions And Exploits
The obvious solution is to increase protection on firmware in flash memory. However, our research also demonstrated that an attacker can exploit other vulnerabilities if the hypervisor allows direct access to the firmware interfaces. For example, we comprised the hypervisor using the resume boot script table in memory that runs when a machine resumes from a sleep state (S3). From a privileged guest, this critical script table structure was changed to access the hypervisor memory spaces. We have published a whitepaper covering the technical details of this S3 resume boot script vulnerability, which has also been independently discovered and discussed by other researchers. In another example, we passed a bad input pointer to the run-time firmware executing in system management mode (SMM) to exploit a vulnerability and inject malicious instructions into this protected area.
In both examples, the attacker first had to exploit some vulnerability in the system firmware of the physical machine such as the SMI handler or BIOS, and then run malicious code with firmware privileges to attack the hypervisor. However, each interface to the firmware that is directly accessible to a virtual machine provides an additional attack vector. Hypervisors can minimize this risk and reduce their attack surface by removing unnecessary guest access to the firmware interfaces and memory locations. Hypervisors can also monitor and proxy interfaces that need to be exposed to the guests and, if possible, apply strict policies on the data passed through them.
Malicious attacks with firmware privileges can compromise the entire system, so it is especially important to apply measures to reduce the risk to applications, software services, and the operating system. You can test your system firmware with available tools such as the open source CHIPSEC framework, which tests for many known vulnerabilities, including the attacks described here. To enable further security testing, we will shortly be releasing new functionality in the CHIPSEC framework to test how hypervisors emulate various hardware interfaces.
For more information, our Black Hat presentation can be found at: http://www.intelsecurity.com/advanced-threat-research/content/AttackingHypervisorsViaFirmware_bhusa15_dc23.pdf
--Yuriy Bulygin and John Loucaides contributed to this blog.