[Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks

["Lengyel, Tamas" <tlengyel@xxxxxxxxxxx>]

Hi Everyone,

I've put together a quick blog entry to remind people that using stubdomains can address issues with QEMU, like the new VENOM vulnerability. Let me know if it would be appropriate for the Xen blog (or if you have any comments)!

Thanks,

Tamas

Hardening Xen against VENOM-style attacks

The recent disclosure of the VENOM bug affecting major open-source hypervisors, such as KVM and Xen, has been circulating in the tech news lately, causing many to reevaluate their security posture when using cloud infrastructures. That is a very good thing indeed. Virtualization and the cloud has been for too long erroneously considered to be a silver bullet against intrusions, malware and APTs.

The cloud is anything but a safe place. VENOM in that sense is just another one in the long list of vulnerabilities that seem to be plaguing hypervisors. However, there are differences between vulnerabilities. While VENOM is indeed a serious bug and can result in a VM escape, which can compromise all VMs on the host, it doesnât have to be. In fact, VENOM-style attacks have been known for a long time. And there are easy-to-deploy counter-measures to mitigate the risk of such exploits, natively available in Xen and KVM.

What is the root cause of VENOM? Emulation.

While modern systems come with a plethora of virtualization extensions, many components are still being emulated. The biggest component of that are usually devices. Devices such as your network card, graphics card and your hard drive. While Linux comes with paravirtual (virtualization-aware) drivers to create such devices, emulation is often the only solution to run operating systems that do not have such kernel drivers. This has been traditionally the case with Windows. This emulation layer has been implemented in QEMU, which has caused VENOM and a handful of other VM-escape bugs in recent years. However, QEMU is not the only place where emulation is used within Xen. For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for performance and scalability reasons. As with QEMU, this emulator has been just as exploitable. This is simply because emulating devices and services is really complex and error-prone to program properly.

This fact, that emulation is complex and error-prone, has been known for a long time. Back in 2011, the Blackhat talk on Virtunoid demonstrated such a VM escape attack against KVM, through QEMU. The author of Virtunoid even cautioned that there will be many other bugs of that nature found by researchers. Fast-forward 4 years and we now have VENOM.

The good news is that there is an easy mitigation available for all present and future QEMU bugs, also mentioned in the original Xen Security Advisory. It is called stubdomains. Stubdomains can nip the whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU into a deprivileged domain of its own. Instead of having QEMU run as root in dom0, a stubdomain has access only to the VM it is providing emulation for. Thus, an escape through QEMU will only land an attacker in a stubdomain, without access to critical resources. Furthermore, QEMU in a stubdomain runs on MiniOS, thus an attacker would only have a very limited environment to run code in (as in return-to-libc/ROP-style), having exactly the same level of privilege as in the domain where the attack started. Nothing to be gained for a lot of work, effectively making the system as secure as it would be if only PV drivers were used. As a sidenote, KVM allows for similar jailing of the QEMU process via the native SELinux sVirt policies.

One would think it is a complex process to take advantage of this protection, when it is, in fact, very simple. Add the following line to your Xen domain configuration and you gain immediate protection against VENOM, and the whole class of vulnerabilities brought to you by QEMU:

device_model_stubdomain_override = 1

Unfortunately, your cloud provider may not allow you to enable this option. They certainly should, so complain loudly and repeatedly if thatâs the case. There is no reason to keep this class of bugs alive.

--

Tamas K Lengyel

Senior Security Researcher

7921 Jones Branch Drive

McLean VA 22102

Email Âtlengyel@novetta.com

_______________________________________________
Publicity mailing list
Publicity@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity