|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks
Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. -anil > On 14 May 2015, at 11:20, Stefano Stabellini > <stefano.stabellini@xxxxxxxxxxxxx> wrote: > > 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 _______________________________________________ Publicity mailing list Publicity@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |