Slashdot Mirror

← Back to Stories (view on slashdot.org)

Xen Security Issue Patched

Posted by kdawson on from the stay-in-your-places-now-children dept.

An anonymous reader sends in word of a privilege escalation security issue identified in the open source Xen hypervisor. Xen has issued a hotfix and urged all users to install it. The problem was disclosed by Secunia last week. A user of a guest domain with root privileges could execute arbitrary commands in domain 0 via specially crafted entries in grub.conf when the guest system is booted.

4 of 41 comments (clear)

  1. Already fixed in some distributions by Anonymous Coward · · Score: 3, Informative

    Why are vulnerabilities Slashdot-worthy? They happen almost daily, and are usually fixed quickly. This has was fixed in RHEL yesterday:

    https://rhn.redhat.com/errata/RHSA-2007-0323.html

    CentOS already carries this fix too.

  2. Re:Oughtta teach 'em by Anonymous Coward · · Score: 4, Informative

    I believe Xen's VM model isn't to try to completely emulate a CPU as other VM products do (QEMU, VMWare, etc.), but instead only abstract it somewhat. I don't think it gives you complete ability to mess with physical memory and arrange it however you please. As such, it gives you a "hypervisor API" for requesting physical memory and controlling its virtual memory mappings.

    In an environment where you can't directly mess with physical memory, you can't really have a bootloader, since a bootloader pulls data from the disk (the kernel, initrd, etc.), using either some BIOS calls or direct hardware access (which will be limited to whatever the bootloader knows how to deal with), places that data in memory, and jumps into it. This sounds like a possible disadvantage, but it has the possible benefit of not requiring anyone to mess with setting up real-/protected-mode, dealing with funky BIOS issues (which may differ among different PC models), and having to use BIOS calls to set up the environment before the real kernel boot.

    In the Xen-VM world, hardware access is abstracted, and the kernel and other necessary code is already loaded for the guest VM, by the host OS.

    Someone correct me if I'm wrong about this (especially the first part about physical memory access)... I can't find the documentation at the moment.

  3. Customer of mine... by cerberusss · · Score: 5, Informative

    Cool to see this on Slashdot. The guy who found the vulnerability is actually a customer of mine. I recently started a business in hosted Virtual Private Servers. Joris van Rantwijk, the bug reporter, was interested to become a customer and I said why don't you try it out for a few weeks?

    As a plus point, I let them boot their own kernels (I trust my custommers). Next thing I know, he tells me to check my /root directory ON MY PHYSICAL MACHINE (i.e. domain 0 in Xen speak) where I find a file describing the exploit...

    Oh don't bother to check out my business' website, it's not translated yet in English... (I'm Dutch).

    --
    8 of 13 people found this answer helpful. Did you?
  4. Re:Have there been many issues with ESX? by cerberusss · · Score: 2, Informative

    This is a moderately scary security issue -- a few of these per year and the current virtualizing trend might start to unravel.
    You're quite right; funny thing is, this is described as "less critical" by Secunia because they say it's not a remote exploit. You have to be in a virtualized machine to start with and they don't call this 'remote'.
    --
    8 of 13 people found this answer helpful. Did you?