Red Hat Bugzilla – Bug 230295
CVE-2007-0998 HVM guest VNC server allows compromise of entire host OS by any VNC console user
Last modified: 2010-07-22 19:25:03 EDT
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
'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):
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
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.
You are unable to switch to the monitor in step 3.
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
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.
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.
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
- 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
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.
fixed similarly in x86_64
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.