Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security IT

Xen Security Issue Patched 41

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.
This discussion has been archived. No new comments can be posted.

Xen Security Issue Patched

Comments Filter:
  • 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>
        • by stevey ( 64018 )

          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

  • Xen and the art of powercycle maintenance.


  • 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!
  • by Anonymous Coward
    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'.
      • by weicco ( 645927 )

        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].
  • 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.
  • Customer of mine... (Score:5, Informative)

    by cerberusss ( 660701 ) on Thursday October 04, 2007 @12:27PM (#20854587) Journal
    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).
  • 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.
    • by demon ( 1039 )
      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???

  • ...words..stuff... (Score:1, Insightful)

    by Joe U ( 443617 )
    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

"Hello again, Peabody here..." -- Mister Peabody

Working...