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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: publicity-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:publicity-
> bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Anil Madhavapeddy
> Sent: 14 May 2015 11:39
> To: Stefano Stabellini
> Cc: Lengyel, Tamas; publicity@xxxxxxxxxxxxxxxxxxxx
> Subject: 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.
> 

No, XenServer does not use stub domains nor is there a plan to. Unless the 
memory footprint of a stub domain can be made <= the memory footprint of a qemu 
process, the impact on our scalability would prevent us from going in that 
direction.
That said, there's no reason why qemu processes need to run in dom0 and I think 
XenServer would embrace the idea of a qemu service domain.

  Paul

> -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
_______________________________________________
Publicity mailing list
Publicity@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity