Bug 464817 - (CVE-2008-4405) CVE-2008-4405 xen: Multiple unsafe uses of guest-writable data from xenstore
CVE-2008-4405 xen: Multiple unsafe uses of guest-writable data from xenstore
Status: CLOSED CURRENTRELEASE
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,source=redhat,public=...
: Security
Depends On: 465937 465938 467684 467685
Blocks: 464818 CVE-2008-5716
  Show dependency treegraph
 
Reported: 2008-09-30 13:17 EDT by Daniel Berrange
Modified: 2009-10-22 12:03 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-22 12:03:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2008-09-30 13:17:32 EDT
Description of problem:
Every paravirt guest (and some fullvirt guests) have a TTY path associated with them for the text console access to the guest domain. The TTY path is allocated at time of VM creation, and is written into xenstored.

xm console  reads the TTY path out of xenstored and opens it to provide admin access to the text console.

The problem is that the TTY path is written into an area of xenstore which is writtable by the guest. So a malicious guest can re-write the TTY path, tricking the host admin into accessing a different TTY than they should.

  eg, if you have a guest called 'demo', with domain ID 5, inside the guest you could do

    # yum install xen
    # xenstore-write /local/domain/5/console/tty /i/am/the/evil/guest

  Then when the host admin tries to connect to the console later


   # xm console rhel5pv
   xenconsole: Could not open tty `/i/am/the/evil/guest': No such file or directory

Not sure yet if this could cause xm console to actually corrupt/overwrite important files, or if its just a inconvenience.


There is a tonne of other info written & read to/from this untrustable area, and some of it *is* serious

For fullvirt guests, the PID of the QEMU device model is written into the device model at  /local/domain/$DOMID/image/device-model-pid

  If a malicious guest did

   xenstore-write /local/domain/26/image/device-model-pid 1

It is possible that in some circumstances, when a host admin later tries to kill the guest, it would in fact kill 'init' process in the host. 


Version-Release number of selected component (if applicable):
xen-3.0.3-64.el5

How reproducible:
Always

Steps to Reproduce:
1. Inside a guest 

  #yum install xen
 # xenstore-write /local/domain/GUEST-DOMID/console/tty /i/am/the/evil/guest

2. On the host

   xm console GUEST-NAME

Also various other checks
  
Actual results:
xenconsole: Could not open tty `/i/am/the/evil/guest': No such file or directory

Expected results:
xm console still works, and does not read data from untrusted areas.


Additional info:
Comment 1 Daniel Berrange 2008-09-30 13:27:25 EDT
This flaw is publically known, since a developer posted a patch to xen-devel without saying that it was security sensitive :-(

Lead of thread:

http://lists.xensource.com/archives/html/xen-devel/2008-09/msg00992.html

Place where it was pointed out to be security problem

http://lists.xensource.com/archives/html/xen-devel/2008-09/msg00994.html
Comment 2 Daniel Berrange 2008-10-02 07:37:15 EDT
There is now a fix available from upstream repository that addresses this in 2 parts

 - Makes most of the xenstore entries under /local/domain/$DOMID read-only to the guest. only 'devices', 'error' and 'control' are now writable by the guest
 - Moves some of the stuff previously under the '/local/domain/$DOMID/devices' section to /vm/$UUID/devices instead

http://xenbits.xensource.com/staging/xen-3.3-testing.hg?rev/e0e17216ba70

This will need to be backported to the Xen in RHEL-5
Comment 3 Josh Bressers 2008-10-03 10:38:52 EDT
I'm moving this bug to the Security Response product for proper tracking as a security flaw.
Comment 4 Josh Bressers 2008-10-03 10:47:39 EDT
I'm giving this a severity of moderate.  Once we have a CVE id, we can fix it in RHEL5 with an async update.
Comment 8 Daniel Berrange 2008-12-18 11:48:45 EST
Turns out the upstream patch is broken

http://lists.xensource.com/archives/html/xen-devel/2008-12/msg00842.html
Comment 9 Jan Lieskovsky 2009-01-06 13:00:52 EST
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-5716 has been reported
due comment c#8.
Comment 12 Chris Lalancette 2009-10-22 12:03:29 EDT
This was released a long time ago, so closing this tracking bug.

Chris Lalancette

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