Slashdot Mirror
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.
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.
Xen and the art of powercycle maintenance.
Thank goodness this was fixed. No longer will we have to worry about bearded miscreants sneaking into Xen and shooting the place up!
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.
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?
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.
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.
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?
If you can read this, I forgot to post anonymously.
Looks like they are not too concerned with security either way:
Server Microsoft-IIS/6.0
X-Powered-By ASP.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.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
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?
/root directory ON MY PHYSICAL MACHINE (i.e. domain 0 in Xen speak) where I find a file describing the exploit...
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
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?
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.
/boot/grub/grub.conf in the domU filesystem?? Makes no sense at all.
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
In the free world the media isn't government run; the government is media run.
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, cdrom/floppy, USB. Guest memory is not virtualized, but is like any app that has mapped a chunk of RAM (where possible ESX does something similar to shared memory where chunks of memory are the same between guests).
A VMware guest does not directly access memory (I'm assuming you mean that it doesn't need to go through any memory manager) and it uses whatever bootloader the guest has on it's disk (grub, lilo, Windows, etc). So your guestimation is incorrect. VMware does emulate a standard bios available on motherboards (phoenix I believe) allowing the bootloaders to work without any hoops at all (I only have to go into that BIOS if I want to change from boot from disk to boot from USB/CDROM/etc, new versions make that as a prompt so I don't have to get in at all anymore). The guest doesn't need direct access because the memory starts for the guest logically at hex 0000, rather than whatever offset it actually is (0FE3). So the bootloader in the guest pulls in the data into it's logical block 0000 and jumps to it at 0000 (it doesn't know about all the rest of the memory before or after it). This is also true for the paravirtualized VMware 6.0 workstation using the new kernel paravirtualization module paravirtopts (that XEN is moving to as well) basically doing something very similar to XEN in that the guest kernel has knowledge it's in a virtual environment and can access things more directly. This is very similar to the above hardware statement, the VMWare memory scheduler makes available to a guest process a chunk of memory, just like with any process that uses a memory scheduler you don't really care about where the memory is only that you have bytes of memory starting a byte 0 going to byte , your program doesn't know that in reality it starts at address 0FE3 in the giant pool of memory the system has. This is the great secret about virtualization just like on unix everything is accessed like a file (memory, NIC card, keyboards, etc are all accessed like a file: open, read, close), everything virtualized is just a program running that is getting scheduled, inside your program it does things.
In a Xen-VM world the guest still runs a separate kernel, if it is paravirtualized the guest & the host need to use the same kernel XEN API (which in the past has basically meant that they had to be the kernel rev as the API was modified with almost every release). Something like Virtuozzo or Solaris domains would be like what I think you are meaning where there is one kernel running and it loads all code for the guests ahead of time and launches the guests into "jails" that interface back to the main kernel (they can have their own libraries, etc but everything uses the one kernel)
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.
There was an exploit
and then it was fixed
slow news day
"Beware of he who would deny you access to information, for in his heart he dreams himself your master."
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.
/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.
I run my Xen DomU's with a single virtual disk per filesystem, no partition tables (the DomU mounts
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.
See http://etbe.coker.com.au/ for my blog.
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 unmodified OSs (without special Xen kernel support) at full speed (software emulation of protected-mode instructions is very slow - the fact that such instructions are not used often means that overall performance may not suffer much). But not owning a machine with such hardware I have not had a chance to test this.
The Dom0 in Xen provides the kernel and initrd to the Xen system for booting, the process which does this runs as root and if it is compromised then you lose.
See http://etbe.coker.com.au/ for my blog.