Xen Security Issue Patched

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.

Comments

Already fixed in some distributions

[Anonymous Coward]

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.

Re:Already fixed in some distributions

[kscguru]

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.
2. Compare "lots of holes, usually fixed quickly" with "very few holes". Vulnerabilities should not exist in this sort of software, no matter how quickly fixed. Would you use SSH if vulnerabilities "happen almost daily, and are usually fixed quickly"? The rate of occurrence of bugs like this is indicative of code quality. Don't be an apologist where security software is concerned.

Xen rooted

[Mister Liberty]

Xen and the art of powercycle maintenance.

Re:Oughtta teach 'em

[Anonymous Coward]

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.

Customer of mine...

[cerberusss]

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

Re:Have there been many issues with ESX?

[cerberusss]

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

why would a domU have grub anyway?

[myowntrueself]

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.

Avoid PyGrub and everything is fine

[Russell Coker]

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 the filesystem.

This doesn't work with PyGrub, I could fix the bug but I haven't bothered - it's easier to just have the kernel and initrd stored outside the filesystem managed by the DomU.

This configuration makes it easier to manage (one kernel and initrd for multiple DomU's) and avoids security issues with PyGrub.