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.
By Assaf Harel