Bug 230295 (CVE-2007-0998)

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.