Bug 230295 (CVE-2007-0998) - CVE-2007-0998 HVM guest VNC server allows compromise of entire host OS by any VNC console user
Summary: CVE-2007-0998 HVM guest VNC server allows compromise of entire host OS by any...
Alias: CVE-2007-0998
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Rik van Riel
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-28 01:03 UTC by Daniel Berrangé
Modified: 2019-09-29 12:20 UTC (History)
2 users (show)

Fixed In Version: RHSA-2007-0114
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-14 15:14:16 UTC

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

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:0114 0 normal SHIPPED_LIVE Important: xen security update 2007-03-14 15:13:30 UTC

Description Daniel Berrangé 2007-02-28 01:03:54 UTC
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, 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):

How reproducible:

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 Berrangé 2007-03-01 19:19:21 UTC
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 Berrangé 2007-03-02 19:42:03 UTC
Some notes for anyone trying to reproduce the steps in comment #1

 - It should actually be 'change hdc /etc/passwd'  rather than 'change cdrom
 - 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 20:28:24 UTC
in xen-3.0.3-25.0.1.el5

Comment 9 Brian Brock 2007-03-06 21:18:52 UTC
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 22:15:00 UTC
fixed similarly in x86_64

Comment 13 Red Hat Bugzilla 2007-03-14 15:14:16 UTC
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.


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