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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

I think it is good. I would also mention the possibility of running PV
(and PVH) guests instead of HVM guests.


On Wed, 13 May 2015, Lengyel, Tamas wrote:
> 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.
>
>
>
> --
>
> www.novetta.com
>
> Tamas K Lengyel
>
> Senior Security Researcher
>
>
> 7921 Jones Branch Drive
>
> McLean VA 22102
>
> Email Âtlengyel@xxxxxxxxxxx
>
>
>

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