Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Bug Cloud Security

Xen Patches 7-Year-Old Bug That Shattered Hypervisor Security (arstechnica.com) 61

Posted by samzenpus from the the-fix-is-in dept.
williamyf writes: ArsTechinca, The Register, and other outlets are reporting that today the XEN project patched a vulnerability in the ParaVirtualized VMs that allowed a guest to access the control OS of the hypervisor. Qubes researchers wrote: "On the other hand, it is really shocking that such a bug has been lurking in the core of the hypervisor for so many years. In our opinion the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again".

This discussion has been archived. No new comments can be posted.

Xen Patches 7-Year-Old Bug That Shattered Hypervisor Security More

Xen Patches 7-Year-Old Bug That Shattered Hypervisor Security

Comments Filter:

  • XEN PV mode is dead (Score:5, Interesting)

    by Anonymous Coward on Friday October 30, 2015 @05:23AM (#50831115)

    The truth is nobody uses para-virtualized VMs anymore. EC2 which was the last bastion for pv xen stopped using it a couple of years ago and moved entirely to hvm model. I'm not even sure that the latest Linux kernel support are compiled with Xen PV support. If you looked at the kernel code for PV XEN support you know what the mess that was so good riddance. You need to understand what PV mode means for hypervisors: a kernel must be specifically modified to talk to a hypervisor so instead of performing a privileged CPU instruction it would call a Hypervisor provided function. I'm sure there were tons of security issues with that approach and many still exists. Anyway PV model is not relevant anymore since Intel introduced hardware virtualization on the CPU. It was introduced to to improve perfromance of VMs but it's not relevant anymore

    • I'm not even sure that the latest Linux kernel support are compiled with Xen PV support.

      You mean, you're not sure if it defaults to Y? Or whether common distributions are enabling it when they build the kernel? The answer to the latter, at least, is yes. AFAICT, though, most people still using PV are using KVM. The rest are using containers.

    • Re: (Score:3)

      by engun ( 1234934 )
      PV and HVM are not mutually exclusive. The basic idea of having a modified, "virtualization-aware" guest-os (a.k.a PV) is a good one and results in better performance. Hardware Virtualization often simplifies the implementation of both the hypervisor and PV on the guest, but does not obviate the need for PV. Using both in tandem can result in even greater performance gains. http://wiki.xen.org/wiki/PV_on... [xen.org]
      • You probably want to link to PVH, not PVHVM for the real relevant approach. That said, HVM usually implies, at a minimum, hardware support for nested page tables. The bug in question is only present when using shadow page tables. Even if you're using PV devices in an HVM or PVH VM, you're using the hardware page tables.

    • The parent post should be considered a NOOP. There's plenty of accurate information available about the different modes and hybrid modes that hypervisors use these days, but reading the above will just make you stupid.

    • That may be the case for cloud deployment. However, there are other very important areas that PVs are being used. For example: qubes, a security focused Linux distribution https://www.qubes-os.org/ [qubes-os.org].

      In addition, there is actually a full spectrum between PV and HVM: http://wiki.xen.org/wiki/Xen_P... [xen.org]. Very few use straight HVM, generally it is HVM + PV Drivers. Linux on Xen ends up using PVHVM. The sweet spot for Open Sources OS under Xen is PVH.

  • "Shattered" really?

    What the hell is in charge of the Gawker-style headlines, because I think that same robot should be made responsible for editing: at least we know it's working.

    • What the hell is in charge of the Gawker-style headlines, because I think that same robot should be made responsible for editing: at least we know it's working.

      You won't believe this one annoying trick for making your clickbait better bait. Advertising works, that's why people use it. Propaganda, likewise.

    • Do you understand the function of a hypervisor? Do you understand how tremendously BAD it is if the host OS can control the hypervisor?

      For seven years, Xen virtualization software used by Amazon Web Services and other cloud computing providers has contained a vulnerability that allowed attackers to break out of their confined accounts and access extremely sensitive parts of the underlying operating system.

      So, imagine ... all these people selling cloud services, making millions and millions of dollars ... no

  • With enough Eyes.. Blah Blah Blah (Score:3)

    by williamyf ( 227051 ) on Friday October 30, 2015 @06:54AM (#50831335)

    ESR Was wrong. Enough Eyes are not enough!

    One needs Enough QUALIFIED AND MOTIVATED eyes, as well as proper test cases, a Quality Assurance group and Technical Guidelines.

    • No you're wrong because you have woefully misunderstood the quote.

      He said with enough eyes all bugs are shallow.

      Not "with enough eyes no bugs exist ever".

      It means that given enough people, once a bug manifests then it's shallow, i.e. easy to fix, for someone.

    • Proprietary software: lawful users may never know about critical security exploits. Even if they do, they are at the mercy of the software's owner; if the owner tells you to toss off, you're SOL.

      FLOSS software: anybody can discover a bug, notify the maintainer, and have it fixed promptly. Even the maintainer won't do it, one also has the freedom to make the fix and recompile the source on one's own.

    • Misunderstanding ESR. Shallow, not non-existent (Score:5, Insightful)

      by raymorris ( 2726007 ) on Friday October 30, 2015 @09:27AM (#50832189) Journal

      ESR didn't say "given enough eyeballs, no bugs exist."
      He said they are -shallow-. "The fix will be obvious to someone". That is, you won't spend a month trying to to figure out exactly why foo sometimes conflicts with widget - with with several people looking at the source (not just the output of the binary), someone will more quickly see why foo conflicts with widget and how to fix it.

      It looks like in this case it was about 48 hours or so to characterize the problem, agree on the proper fix, code it, test, patch the major public clouds, and release it publicly. Guessing that patching the public clouds took 24 hours, that's about 24 hours for understanding the problem, discussing it fixing it, and testing. Not bad. Here's a quote from CATB with the context of the "bugs are shallow" part:

      ---- ... if any serious bug proved intractable. Linus was behaving as though he believed something like this:

      8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

      Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.

      My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it.

      ----

      It's about bugs not being intractable - they aren't extremely hard to figure out, "the fix will be obvious to someone". That doesn't mean they never existed.

      • First of, to some other chap that called me a shill (fortunately, down modded), my disbelief about the many eyes is not new, nor is it related to FOSS versus closed source. Please see my posting history on /.

        Second, this bug was "Unshallow" seven (7) years... 'Nuff Said!

        Let me explain using my favourite example: The Metafile fiasco of 2005.

        Here we had Two (2) Codebases. One Closed Source (Windows) and one FOSS (Wine). BOTH codebases contained the error. It took 10 years for someone (the guys at Sunbelt Soft

        • Have a read of the relevant sections of the oldest, most original CATB you can find. I think you'll see it says the same thing. You see, he was talking about the (then new) troubleshooting process that Linus had implemented.

          The solution to the metafile bug didn't require deep meditation for ten years. If you don't know there is a bug, that doesn't mean it's buried deep, it just means you don't know there's a bug.

          Of course to prevent bugs you need educated developers, good testing, etc. That's all true. An

  • Bugs happen, even in hypervisors (Score:3)

    by martyros ( 588782 ) on Friday October 30, 2015 @07:52AM (#50831539)

    Go do LWN's search page [slashdot.org], uncheck all the boxes except for "security vulnerabilities", and then search for "KVM". Or Qemu, or Linux or Xen.

    You'll find that all hypervisors have privilege escalation bugs discovered. However, this is the first one discovered in the Xen PV interface in a long time.

  • that would not let similar flaws to plague the hypervisor ever again

    Can we trust people to critique code who can't even manage English grammar? There's a basic principle here: All writing needs an editor. What looks good to the person who wrote it can have bad syntax.

    • that would not let similar flaws to plague the hypervisor ever again

      Can we trust people to critique code who can't even manage English grammar?

      Yes. Very few program is written in English. C is more common.

      And looking at the Qubes OS team https://www.qubes-os.org/team/ [qubes-os.org], I'd bet English isn't the primary language for most of them.

  • People who aren't going to participate proclaiming how others should do something.
    • The Qubes OS people do participate in Xen's development (http://xenbits.xen.org/gitweb/?p=xen.git&a=search&h=HEAD&st=commit&s=marek).

  • On the other hand, it would be a good idea to people stop harassing open source projects when serious and/or old bugs are discovered *and* fixed.

    Nasty 7 years old bug discovered? Bad indeed.

    Nasty 7 years old bug *FIXED*? Good, very very good.

    Once you decide not to throw everything through the Windows, I mean, window every year ("fixing" old bugs with new bugs), you must expect that old flaws will one day be discovered. And fixed.

    There're too many criticizers nowadays - but almost none of them got his hands

  • I have no idea what Hypervisor is but all I keep envisioning is Pin*Bot.
  • Privilege escalation vulnerability caused by a buggy Memory Management Unit, instead of failing safely - it fails bad ...

  • The actual bug is shown in the original article. The author says "It appears the seven-year-old Xen bug is caused by an entanglement of C macros, bit masking, and Intel x86's fiddly page table flags" but fails to explain exactly what's going on (probably he doesn't understand it himself). Can some explain what actually happens in this line and what failure modes caused the check to be bypassed?

    The fact that such a simple-looking line could result in such seriously flawed code tells me that programming sec

  • I dumped XEN for VMware last year and haven't looked back. The deciding factor (not to mention sliding market share, lack of compatible backup products, and weak tech support) was a VM simply 'disappeared' due to a faulty clean up process. The faulty process deleted the VM and support told me to call data restoration.. When I asked for the number, he said, "no, I mean your inhouse data restoration, your backup administrator"... VMware has so much of the market every single virtual product or offering ju

Slashdot Top Deals

It is not best to swap horses while crossing the river. -- Abraham Lincoln

Close