Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Xen Security Issue Patched

Posted by kdawson on Thu Oct 04, 2007 10:27 AM
from the stay-in-your-places-now-children dept.
Security IT
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.
+ -
story

Related Stories

Submission: XEN rooted by Anonymous Coward
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Xen Security Issue Patched 41 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Already fixed in some distributions (Score:3, Informative)

    by Anonymous Coward on Thursday October 04 2007, @10:49AM (#20852849)
    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 [redhat.com]

    CentOS already carries this fix too.
    • It all depends who is editor at the moment.

    • Re: (Score:3, Insightful)

      by kscguru (551278)
      This one is newsworthy because:
      1. If the guest can take over the host, this is an EXTREME vulnerability. VMs are used for security research sandboxes, intrusion containment ... hosting providers tend to sell root access to Xen guests. The Xen privilaged parts (e.g. dom0) tend to run within trusted networks. This is as bad as a remote root hole - probably worse, because it can affect a lot more machines. See a write-up about a Gartner report fearing exactly this sort of hole [cmp.com].
      2. Compare "lots of holes, usual
      • Does the default Debian Etch installation activate pygrub? I don't see any mention of it in any of the files in the xen config directory.
        • No, it doesn't. Also, it's coded by someone from RedHat:

          #
          # GrubConf.py - Simple grub.conf parsing
          #
          # Copyright 2005-2006 Red Hat, Inc.
          # Jeremy Katz <katzj@redhat.com>

        • No. When the Debian Xen packages are installed no guests are created.

          For pygrub to be used you must have it explicitly enabled in the configuration files for the Xen guest, located beneath /etc/xen.

          It will only be used if you've manually created a new Xen guest and chosen to use pygrub. Many (most?) Debian users create their new Xen guests via my xen-tools [xen-tools.org] software and that doesn't even support pygrub setups at the moment...

          If you see no mention of pygrub in /etc/xen/* then you're almost certainly saf

    • There was an exploit
      and then it was fixed
      slow news day

    • Re:Oughtta teach 'em (Score:4, Informative)

      by Anonymous Coward on Thursday October 04 2007, @11:27AM (#20853523)
      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.
      • I believe the bootloader only runs for a short while so maybe they can use emulation for running the bootloader stuff safely.

        Then switch to "native" once you hit the kernel stuff etc.

        Probably a lot more work tho.
      • Ummm... you are incorrect regarding VMware CPU emulation and being able to have a bootloader without having direct access to physical memory.

        VMware does not do any CPU emulatation at all. The physical CPU underlying it is visible to any guest, including all of the CPU's capabilities (i.e. MMX, SSE, etc). VMware is acts as scheduler for the CPU, each of the guest VM's are merely programs running inside VMware. VMware additionally does emulate particular pieces of the hardware: bios, motherboard, NIC, cdro
      • The traditional operation of VMWare has been to simulate (in software) operations that are not permitted by hardware (for example requests to change virtual memory mappings). The default mode of operation of Xen is to have the Xen hypervisor expose an API for Xen enabled kernels to use to request such operations (it's basically a system call to change memory mappings etc).

        I believe that recent versions of VMWare and Xen support the virtualisation features of the latest Intel and AMD CPUs so they can run un

  • Xen and the art of powercycle maintenance.


  • Goodbye Gordan! (Score:1, Funny)

    by Anonymous Coward
    Thank goodness this was fixed. No longer will we have to worry about bearded miscreants sneaking into Xen and shooting the place up!
  • This is a moderately scary security issue -- a few of these per year and the current virtualizing trend might start to unravel.

    The XenSource code base (well, some of it at least) is Open. Its competitor, ESX from VMware, isn't. Philosophy aside, how has ESX been doing on the security front?

    • Re: (Score:3, Informative)

      by cerberusss (660701)

      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'.

      • What if virtual machine uses Plan9 and attack is initiated from remote machine across the network, would that count as remote hole? :) I'm not sure if that's even possible though...

    • How would we know? VMWare hides what their updates are really about [lonesysadmin.net].
    • If there's any useful information on that site it's well-hidden. A search for "pygrub" turns up zero results. I suspect you are just spamming.
  • we were told that it was not possible to do a VM root kit...

    Now that that pdf from both Xen and VMWare read like someone trying hard to sell a product is another thing.
  • A security issue fixed in the state of Zen?

    That's amazing. Chalk another victory up for the pocket-protector crowd. Is there anything they can't do?
  • Looks like they are not too concerned with security either way:
    Server Microsoft-IIS/6.0
    X-Powered-By ASP.NET
  • Xen Security Issue Patched: The Black Mesa science team successfully closed the portal that was inadvertently opened this morning during the resonance cascade scenario.
  • 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).

  • why would a domU have grub anyway? (Score:3, Interesting)

    by myowntrueself (607117) on Thursday October 04 2007, @01:52PM (#20855897)
    A paravirtualised domU does not need a boot loader and does not even have access to its own kernel. Which is nice because you can give it an unmodular kernel which is more secure in as much as a user on that domU cannot load their own (potentially exploiting) kernel modules.

    Its only an HVM domU that would need a boot loader and its own kernel.

    I've read through TFA and the Xen mailing list and I can't see anything that says whether this affects both paravirtualised *and* HVM or just one or the other...?

    In the case of paravirtualised, why on earth would the creating the domU even *look* for a /boot/grub/grub.conf in the domU filesystem?? Makes no sense at all.
    • Paravirtualized domUs can be booted by using a pseudo-bootloader called pyGrub, which mostly emulates GRUB in its functionality, allowing a self-contained domU image to self-bootstrap (no dom0-hosted kernel image is needed). Unfortunately the script runs within dom0, which is where the issue comes in - since it's executing within that domain, and with root's privileges (it has to be able to examine the root block device), I guess it was only a matter of time till someone figured out how to make it do... thi
      • Unfortunately the script runs within dom0, which is where the issue comes in

        And so dom0 gets to run a script against content in a file in domU...

        My God thats just insane and is *asking* for trouble!!!

        What *moron* thought this would be a Good Idea???

  • 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.

    Seriously, guys, Star Trek:TNG is off the air. You can stop writing like this now.
  • PyGrub expects that the root device is partitioned and searches on partition 1 for the GRUB configuration. This is bad because it requires you to have a partition table which makes things inconvenient if you want to resize the disk space provided to the virtual machine.

    I run my Xen DomU's with a single virtual disk per filesystem, no partition tables (the DomU mounts /dev/vbda or /dev/hda etc) and I can easily resize any filesystem at any time by stopping the DomU, extending the LVM volume, and extending t

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.