A recently discovered critical vulnerability presents yet another case study for the shortcomings of the isolation/virtual machine model for cybersecurity.
The vulnerability, CVE-2019-14378, has a severity of 8.8, and was first published in the National Vulnerability Database on July 29th, 2019. The vulnerability affects QEMU, the popular open source machine emulator and virtualizer.
Short for “Quick Emulator”, QEMU is an embedded C/C++ code software that acts as an interface between a guest system and the actual hardware it uses. Known as “hypervisors,” this method allows machines to stay separate from other machines using the same host, to protect themselves in the event another machine is infected. Using a “virtual machine” also allows you to test out different software and apps not used by your host system – including suspected malware – without worrying that it’ll affect your physical system. But what happens when a vulnerability allows a hacker to break out from one hypervisor and execute code on the host computer itself?
This is the case with CVE-2019-14378, which can allow a malicious actor to run malware on the host computer from a virtual machine. The flaw could allow hackers to carry out “virtual machine escape,” letting the guest operating system attack the host operating system that runs QEMU, execute code at the QEMU level, or crash QEMU process altogether. In other words, an embedded vulnerability in one stack can lead to compromised components elsewhere in the system.
The vulnerability also reveals how even if the coding languages you use are safe from arbitrary code execution – as is the case with Java – once an attacker manages to penetrate the app that uses C/C++, they can exploit this vulnerability to break out of the hypervisor and send malware to a completely separate virtual machine.
In sum, C/C++ code is everywhere, and security architectures can still be vulnerable to hacks that target C/C++ hypervisors like QEMU, even if they don’t use C/C++ code.
The QEMU vulnerability is by no means the first example of how virtual machines can be hacked. There are many examples related to open source components (ex. Linux KVM) and proprietary ones. For instance, at the Pwn2Own security competition in 2017, a group of white hat hackers from the Chinese internet security firm Quihoo 360 needed less than 90 seconds to demonstrate a successful escape from a VMWare workstation.
They carried out the escape by first exploiting a heap overflow bug in Microsoft Edge web browser, and then they “exploited a bug within the VMware hypervisor to escape from the guest operating system to the host one. All started from, and only by, controlling a website,” Qihoo 360 Executive Director Zhen Zheng told reporters following the successful hack.
Mitigation: Using Runtime Integrity
While hypervisors and virtual machines can be an effective line of defense, they are useless if their proper functionality and integrity is not guarded during runtime. For that reason, standards such as NIST 800-53 and ANSI/ISA‑62443 specify integrity requirements. One key method to achieve that is by adding Embedded Runtime Integrity controls, which in this case will do exactly that – ensure the isolation and separation work as intended.