back to article Explo-Xen! Bunker buster bug breaks out guests from hypervisor

A super-bug in the Xen hypervisor may allow privileged code running in guests to escape to the underlying host. This means, on vulnerable systems, malicious administrators within virtual machines can potentially break out of their confines and start interfering with the host server and other guests. This could be really bad …

  1. Anonymous Coward
    Anonymous Coward

    Patches are available from Xen 4.3 (not 4.5 as stated in the article)

    The following statement is wrong!

    > The bug was discovered by Jérémie Boutoille of Quarkslab, and publicly

    > patched on Tuesday for Xen versions 4.5 to 4.7 and the latest

    > bleeding-edge code.

    Patches are available for

    xsa182.patch [for] xen-unstable, Xen 4.7.x

    xsa182-4.6.patch [for] Xen 4.6.x

    xsa182-4.5.patch [for] Xen 4.5.x, 4.4.x, 4.3.x

    1. diodesign (Written by Reg staff) Silver badge

      Re: Patches are available from Xen 4.3 (not 4.5 as stated in the article)

      Oh, oops - sorry, didn't see those numbers. I'll fix. Please email if you spot anything wrong.


  2. BinkyTheMagicPaperclip

    Please be more critical of the Qubes project

    From what I can see the Qubes project contribute nearly sqrt(F-all) to the upstream project they depend on (Xen).

    So they don't like Xen, either

    1) Shut up and contribute code

    2) Switch in KVM if it's so easy

    3) Write their own hypervisor - both FreeBSD and OpenBSD have done this (although OpenBSD haven't shouted about it much, and it's a tad less functional than other implementations). These, and KVM, are type 2 hypervisors though, whilst Xen is type 1 (it will run on bare metal without a kernel, and there are a choice of dom0 kernels. Note that FreeBSD current is now dom0 capable, although there's no passthrough yet)

    1. Anonymous Coward
      Anonymous Coward

      Re: Please be more critical of the Qubes project

      Indeed. Looking at Qubes project security bulletins, they often appear to be designed to create maximum publicity for Qubes. When you look at their Xen critique from November last year, Qubes raised a number of points, and then failed to engage further. I am not aware of any other project/vendor who uses security bulletins in this way.

      I also find the following portion of this Qubes security bulletin revealing: "A more radical reader might be of the opinion that we should completely replace Xen with some other hypervisor. Such an opinion is surely not unfounded, as we have previously expressed our disappointment in the Xen security process [5]. Sadly, not much has improved over the past several months. Moreover, even though Qubes is now based on a hypervisor-abstracting architecture ("Odyssey"), which should make switching to a different VMM a relatively easy task, the primary problem that remains is the lack of a good alternative hypervisor to which we could move [6]."

      So in other words, every alternative available is worse, in the view of the Qubes team. But of course this is not covered in this story

    2. Nate Amsden Silver badge

      Re: Please be more critical of the Qubes project

      I do not use KVM but did not believe the claim that it is a type 2 hypervisor, did a quick search and came up with

      "Myth #1: KVM is type 2 hypervisor that is hosted by the operating system, and isn’t a bare metal hypervisor.

      This is a persistent myth, but the truth is that KVM actually does run directly on x86 hardware. People assume it is a type 2 hypervisor because one of the ways that it is packaged is as a component of Linux - so you can be running a Linux distribution and then, from the command-line shell prompt or from a graphical user interface on that Linux box, you can start KVM. The interface makes it look like it is a hosted hypervisor running on the operating system, but the virtual machine is running on the bare metal - the host operating system provides a launch mechanism for the hypervisor and then engages in a co-processing relationship with the hypervisor. . In a sense, it is taking over part of the machine and sharing it with the Linux kernel."

      I assume the misconception is similar for those people that think Vmware ESX/ESXi runs on top of linux because they see linux messages on bootup.

      (Vmware customer since 1999 - haven't seen anything in Xen or KVM that has gotten me interested in evaluating them as alternatives - Linux user since 1996 so not like I don't have experience with open source stuff)

      1. BinkyTheMagicPaperclip

        Re: Please be more critical of the Qubes project

        It's a persistent misconception because it's true. KVM cannot be run without Linux. Xen can, and is, run without Linux. There's the well known kernels (Linux, Solaris and derivatives, NetBSD), the in progress (FreeBSD) and the custom (MiniOS, shipped as an example with Xen, and third party options).

        I've just checked the documentation for RHEV, and it's clearly a stripped down Linux. At one point KVM.ko did load under FreeBSD, but that's only because of FreeBSD's Linux compatibility, and even then it didn't work well.

        Personally I think of KVM as an optional Qemu accelerator, coupled with some excellent pci passthrough tools. Xen's paravirtualised architecture means it can be quite different, and it's (in my opinion), considerably better integrated than KVM, plus has a (now free) turnkey system using a custom Linux distribution, looking not dissimilar to ESXi.

        Obviously there's also the cost, and supportability issues. VMWare is excellent, but will cost a lot in some configurations, has a limited set of supported hardware, and most irritating keeps dropping support for perfectly functional hardware in new releases. At least with Xen/KVM, it's using standard OS drivers.

  3. Pascal Monett Silver badge

    Has Xen been written by competent developers?

    Bit of a cheeky one there, IMO.

    Given that I couldn't write a VM to save my life, I think that Xen has some pretty damn good programmers.

    Nobody's perfect, of course, but VM programming seems to me to be especially difficult. With any application, new security holes are regularly discovered. Some of them are trivial. With VMs there have been, to my knowledge, no trivial exploits.

    That's not bad right there, in my book.

    1. Dwarf

      Re: Has Xen been written by competent developers?

      @Pascal Monett.

      Agree fully. Have an upvote !

      Perhaps those who think this is poor should release their own virtualisation platform to complete with the rest of the market.

  4. nijam Silver badge

    Not that I'm an expert, but as a general principle I would expect that the "hardware" features used to implement hypervisors are likely to have at least as many bugs.

    1. BinkyTheMagicPaperclip

      You'd be right there. There's plenty of workarounds for duff hardware, and at least on the KVM side (probably Xen too) some features are based on whitelists and blacklists. i.e. Intel and AMD have told the virtualisation project that a particular chipset supports this feature, but it's not discoverable, so it has to be enabled/disabled based on PCI IDs, etc.

      The number of BIOSes with fully or partially broken ACPI or DMAR tables is huge, and outside server boards, vendors don't tend to care as VT-d has been a rarely used feature on consumer kit until recently, and ACPI anomalies can often be worked around. Solutions include 'buy a new motherboard' or workarounds such that the ACPI/DMAR tables work, but only when certain devices are enabled/disabled (i.e. the BIOS does not correctly modify the tables based on installed devices, as it should).

      BIOSes have done a lot more than load a boot sector, for a very long time.

    2. Roo

      "Not that I'm an expert, but as a general principle I would expect that the "hardware" features used to implement hypervisors are likely to have at least as many bugs."

      Few people appear to pay attention to the Errata sheets published by CPU vendors, you could become an expert on the topic if you read a couple of them. :)

      I suspect folks who have read those errata sheets and who are serious *serious* about securing their hardware they would give things like hypervisors and x86 hardware a miss and maybe looked for something a bit easier to lock down.

  5. fnj

    Difficult to phrase this without condescending

    "More tidier" code? Really? All your proofreaders who successfully achieved a grammar school education missed this?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like