Hacker News Reader

Comment by sansnomme | Hacker News Reader

Why would it compromise the hypervisor though?

There's no separate "hypervisor" component. QEMU itself is the hypervisor. That is, QEMU is a regular computer program whose functionality is to emulate a machine; that emulated machine is called a virtual machine. QEMU itself runs on a regular computer OS like Linux. (QEMU with hardware acceleration is a perfectly good and quite common production-grade virtualization setup.) All the code described here is part of QEMU itself, not part of the virtualized OS running inside QEMU.

If a VM running inside QEMU is able to compromise QEMU's code, it then runs with the privileges of QEMU on the host. The host, the regular OS running QEMU, is colloquially called "the hypervisor." And in most production virtualization setups, there is nothing of interest on the host other than some QEMU processes itself, i.e., anything valuable on the host is perfectly well accessible to QEMU, and therefore to malicious code that has taken over the QEMU process.

It's quite reasonable to distinguish QEMU from the hypervisor: QEMU typically runs with strictly lower privileges.

The "hardware acceleration" that helps QEMU emulate a computer operates in root VMX and non-root VMX (when actually executing guest instructions) modes. When operating in root VMX mode as a supervisor, it has approximately the highest privileges in the system (ignoring SMM), as it is operating in host ring 0. QEMU runs in host ring 3, making it a typical user mode process. If you manage to compromise QEMU (and only QEMU), you have only escaped into host user mode. In that case you haven't compromised the hypervisor, merely the virtual machine monitor.

If, on the other hand, you manage to compromise KVM (or vhost) you could reasonably claim to have actually compromised the hypervisor.

Type 2 hypervisors make this generally much uglier than type 1, but it's reasonable to say that the hypervisor in a type 2 deployment is limited to the kernel component rather than the user-mode VMM.

Where do you get this type of academic education of virtualization techniques?

Depends on your country, but I suppose it has to do with theoretical computer science at the master level, you can see a lot of academic content around this (in Paris, France for example): https://wikimpri.dptinfo.ens-cachan.fr/doku.php (yes, HTTPS is broken…)

Some of it is academic study (BS and MS at Georgia Tech) -- that helped with the theory and a bit of the breadth. That said, most of what I know of modern virtualization was more or less "on the job" from working on Google Compute Engine. Lots of practical experience understanding virtualization boundaries, and really really enormous access to historical domain experts in the space.

> it has approximately the highest privileges in the system (ignoring SMM)

and MINIX in case of Intel :-)

> anything valuable on the host is perfectly well accessible to QEMU

In a well configured KVM instance QEMU obeys the principle of least privilege as much as possible, that is it can only access the resources it needs to do its job.

In practical terms, this means QEMU is confined (via SELinux, cgroups, Unix permissions, seccomp) to only access resources for the VM it is running; taking over QEMU does not give you access to "anything valuable on the host".

Of course, having remote code execution in QEMU is awful; it can be a base for exploiting a kernel vulnerability to get root access. Luckily this bug would not be exploitable in a production setting.

I think the intersection of conigurations where QEMU is using the SLiRP networking and where it's carefully configured to use the (non-default) sandboxing is pretty small. The sandboxing configs are typically associated with use of libvirt where you'll probably be using tun/tap or some other non-slirp kind of networking.

Exactly, this is why this bug is unlikely to be exploitable in production (OpenStack for example only runs QEMU via Libvirt).

In a production system, it's highly unlikely that there is anything on the host besides the VM. You're not running qemu on one core and an unvirtualized database on another. Amazon is not running an S3 file server on the same physical machine that's being an EC2 host. The only valuable thing is other VMs.

And I think that there is no common configuration of OpenStack or libvirt that assigns unique access control labels per VM. Every qemu runs with the same privileges, ergo one exploited qemu can laterally attack another. (But maybe there's something nifty I'm missing?)

(Agree that for the use case of desktop virtualization, a good SELinux config can keep it from accessing your browser cookies.)

SVirt will usually use a per-VM label that should inhibit direct lateral interaction.

FWIW, sVirt is the "code name" for Libvirt's SELinux labeling scheme. It uses SELinux multi-category security to ensure that each QEMU can only access resources destined to one VM.

Reply on news.ycombinator.com