Bug 525740 (CVE-2009-3525) - CVE-2009-3525 Xen: PyGrub missing support for password configuration command
Summary: CVE-2009-3525 Xen: PyGrub missing support for password configuration command
Status: CLOSED ERRATA
Alias: CVE-2009-3525
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: https://bugzilla.redhat.com/show_bug....
Whiteboard: impact=moderate,source=bugzilla,repor...
Keywords: Security
Depends On: 518124 525142 526780
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-25 13:59 UTC by Jan Lieskovsky
Modified: 2019-06-08 12:50 UTC (History)
7 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-11-05 17:36:37 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1472 normal SHIPPED_LIVE Moderate: xen security and bug fix update 2009-10-01 17:55:29 UTC

Description Jan Lieskovsky 2009-09-25 13:59:33 UTC
pyGrub bootloader used to boot Xen para-virtualized guests did not have support for password command as supported by normal grub.  If this option was used in grub.conf, it did not restrict users with access to para-virtualized guest's console from booting guest or changing kernel boot parameters without providing configured password.  This could allow user with access to VMs console to get root privileges on the guest's operating system.

Upstream patches:
-----------------
http://xenbits.xensource.com/xen-unstable.hg?rev/8f783adc0ee3
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/a28c9c2fa8de
http://xenbits.xensource.com/xen-unstable.hg?rev/e513d565c8f1
http://xenbits.xensource.com/xen-unstable.hg?rev/67f1b8b32585
http://xenbits.xensource.com/xen-unstable.hg?rev/168f0cfeded0

CVE Request:
------------
http://www.openwall.com/lists/oss-security/2009/09/25/1

Comment 1 Jan Lieskovsky 2009-09-25 14:00:17 UTC
Steps to Reproduce (taken from BZ#518124):
------------------------------------------
xm create -c guest
press space bar to stop the grub count down
press e to edit
select the kernel line and press e
Append a "1" to the end of the kernel line and press return
press "b" to boot

Actual results:
System boot to init 1

Expected results:
Pygrub prompt should request a password when you attempt to edit grub during
boot.

Additional info:
grub.conf file contents:
default=0
timeout=5
password --md5 *********************
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-128.el5xen)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-128.el5xen ro
root=/dev/vg/djc2bdb_rootvg/djc2bdb_roo
otlv console=tty0 console=xvc0
        initrd /initrd-2.6.18-128.el5xen.img

Comment 2 Jan Lieskovsky 2009-09-25 14:36:15 UTC
This issue affects latest versions of xen package, as shipped with 
Fedora releases of 10 and 11 (xen-3.3.0-1.fc10 and xen-3.3.1-11.fc11).

Please fix.

Comment 3 Tomas Hoger 2009-09-29 09:19:33 UTC
This technically is an enhancement, but it was decided to tag this as security, as pyGrub does not come with documentation explaining which configuration commands of the (real) grub are supported.  Users therefore expect it to support all commands recognized by normal grub and expecting password setting to be enforced by pyGrub too.

Comment 5 errata-xmlrpc 2009-10-01 17:55:32 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1472 https://rhn.redhat.com/errata/RHSA-2009-1472.html

Comment 7 Chris Lalancette 2009-10-02 06:53:32 UTC
(In reply to comment #3)
> This technically is an enhancement, but it was decided to tag this as security,
> as pyGrub does not come with documentation explaining which configuration
> commands of the (real) grub are supported.  Users therefore expect it to
> support all commands recognized by normal grub and expecting password setting
> to be enforced by pyGrub too.  

Hm, I just saw this now, and I have to say that it is very, very odd that this is tagged as security.  The pygrub password protection feature provides absolutely no security at all.  In point of fact, due to the architecture of pygrub, it can't.  All pygrub does is run as a process on dom0, loopback mount the image file the contains the guest disk, extract the kernel and initrd, and then boot the guest from that kernel+initrd.  Adding password protection to pygrub disables this pretty grub-like interface, but there is nothing at all that prevents a user from doing the same loopback mounting steps by hand and booting the kernel that way.  It's not even preventable using user/groups (instead of root, for instance), since by definition a user must have access to a guest hard drive image in order to boot it.

So why do we think this is a security issue?

Chris Lalancette

Comment 10 Marco Jaworek 2010-02-19 17:27:31 UTC
Hello Jan, Chris,

"This could allow user with access to VMs console to get
root privileges on the guest's operating system."

Do you mean Xen's xm console?

So this is security risk or no?

Comment 11 Michal Novotny 2010-02-22 09:37:20 UTC
(In reply to comment #10)
> Hello Jan, Chris,
> 
> "This could allow user with access to VMs console to get
> root privileges on the guest's operating system."
> 
> Do you mean Xen's xm console?
> 
> So this is security risk or no?    

This is not a security risk. It may increase security a little but like Chris stated in comment #7 I don't think is a security issue. Let me clarify the situation: For PV guests the pygrub is run before the actual domain boot - it extracts the kernel and initrd files from the VM image. It always allowed you to choose the image and/or edit kernel line before booting. This line was then passed to the PV guest and booted. You were able to edit the kernel line to pass init 1 parameter there to boot to single user mode. This patch is adding option to read 'password' field in /boot/grub/grub.conf file and require password for this kind of changes like editing kernel lines - this *may* increase security a little from this point of view but not from the other. You can always mount an image file as a loopback device and edit the /boot/grub/grub.conf manually. Of course, you have to be root to do that but when you try to run a PV guest using 'xm create -c PVguest' you have to be root as well so how does it increase security then?

Michal

Comment 12 Vincent Danen 2010-11-05 17:36:37 UTC
Fedora 14 (xen-4.0.1) has this change, so I'm going to close this bug as now Red Hat Enterprise Linux 5 and latest Fedora have this.  It does not look like Fedora 13 has the changes, however the above comments indicate that this is more a security enhancement than a fix.


Note You need to log in before you can comment on or make changes to this bug.