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.
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 /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
in xen-3.0.3-25.0.1.el5
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. http://rhn.redhat.com/errata/RHSA-2007-0114.html