Bug 230295 - (CVE-2007-0998) CVE-2007-0998 HVM guest VNC server allows compromise of entire host OS by any VNC console user
CVE-2007-0998 HVM guest VNC server allows compromise of entire host OS by any...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rik van Riel
impact=important,source=redhat,report...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-27 20:03 EST by Daniel Berrange
Modified: 2010-07-22 19:25 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2007-0114
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-14 11:14:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to remove QEMU monitor access from the VNC server (2.99 KB, patch)
2007-03-01 14:19 EST, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Daniel Berrange 2007-02-27 20:03:54 EST
Description of problem:
A few months back, the VNC server code in QEMU was extended in upstream
xen-devel, adding the 'feature' of monitor access by using Ctrl+Alt+2. Well, the
monitor allows you to do such fun commands such as changing the CDROM backing
file. Of course there's no validation on what files you map to the CDROM device,
and the QEMU instances for Xen run as root. 

Implication: if you have a fullyvirtualized guest VM running the VNC server,
then any user with access to the VNC server can happily enter a monitor command
such as

  'change cdrom /etc/passwd'. 

Which will map the /etc/passwd file through to the guest VM as /dev/hdc,
read-write. So, aforementioned VNC console user can now login to the guest OS,
and by writing to /dev/hdc in the guest, change the /etc/passwd file in the
host. This is most certianly not what the host administrator expects when giving
access to a guest VM's VNC console.

In RHEL-5, we have at least changed the default XenD config so that the VNC
server is restricted to listen on 127.0.0.1, however, there is no password
authentication on by default. Even if there was a password by default, VNC
password auth is *very* weak due to old algorithm, and limited key size.

So any HVM guest running with VNC console enabled should be considered on a par
with a local root exploit, and if the admin lets it run on a public IP, then its
effectively a remote exploit too.

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

How reproducible:
Always

Steps to Reproduce:
1. Assuming a running HVM guest with vnc=1 in the config file
2. As an unprivileged user connect to the guest console with vncviewer
3. Switch to monitor with Ctrl+Alt+2
4. Enter  'change cdrom /etc/passwd'
5. Login into guest OS
6. Read/write from/to /dev/hdc 

Actual results:
You can view & update the host OS' /etc/passwd  from within the guest OS,
without ever having needed to authenticate as root in the host.

Expected results:
You are unable to switch to the monitor in step 3.

Additional info:

NB,the one use case for accessing the monitor is to be able legitimately change
the CDROM device during installation of a guest OS which comes on many disks.
Disabling the monitor will leave users with no way to change the CDROM device
backing file. 

If we need to support CDROM media changes, then we really need to do the work to
make QEMU watch XenStored for virtual disk config updates. So root could do 'xm
block-dettach hdc' and 'xm block-attach hdc disc2.iso' and never need to
directly use the monitor via the VNC console.
Comment 3 Daniel Berrange 2007-03-01 14:19:21 EST
Created attachment 149043 [details]
Patch to remove QEMU monitor access from the VNC server

This patch removes access to the QEMU monitor via the VNC server. It does this
by removing the code which looks for the Ctrl+Alt+2  sequence, as well as extra
code for adapting certain keycodes under the monitor.
Comment 5 Daniel Berrange 2007-03-02 14:42:03 EST
Some notes for anyone trying to reproduce the steps in comment #1

 - It should actually be 'change hdc /etc/passwd'  rather than 'change cdrom
/etc/passwd'
 - Also make sure you have SELinux turned off - ordinarily SELinux will only
allow you access to block devices or files in /var/lib/xen/images. NB even with
SELinux on though, the guest could map the block device corresponding to the
host's filesystem
 - Finally /etc/passwd was probably a bad choice because its a very small file
and thus you can't get much (if any) useful data out in the guest -
/root/install.log  or some other multi-MB file is a better test

Comment 7 Rik van Riel 2007-03-05 15:28:24 EST
in xen-3.0.3-25.0.1.el5
Comment 9 Brian Brock 2007-03-06 16:18:52 EST
appears to be fixed on i386 with xen-3.0.3-25.0.1.el5 and kernel 2.6.18-8.1.1.el5xen

ctrl-alt-2 appears to now be a noop.
Comment 10 Brian Brock 2007-03-06 17:15:00 EST
fixed similarly in x86_64
Comment 13 Red Hat Bugzilla 2007-03-14 11:14:16 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2007-0114.html

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