Description of problem: Every paravirt guest (and some fullvirt guests) have a TTY path associated with them for the text console access to the guest domain. The TTY path is allocated at time of VM creation, and is written into xenstored.

xm console reads the TTY path out of xenstored and opens it to provide admin access to the text console.

The problem is that the TTY path is written into an area of xenstore which is writtable by the guest. So a malicious guest can re-write the TTY path, tricking the host admin into accessing a different TTY than they should.

eg, if you have a guest called 'demo', with domain ID 5, inside the guest you could do

# yum install xen # xenstore-write /local/domain/5/console/tty /i/am/the/evil/guest

Then when the host admin tries to connect to the console later

# xm console rhel5pv xenconsole: Could not open tty /i/am/the/evil/guest': No such file or directory

Not sure yet if this could cause xm console to actually corrupt/overwrite important files, or if its just a inconvenience.

There is a tonne of other info written & read to/from this untrustable area, and some of it is serious

For fullvirt guests, the PID of the QEMU device model is written into the device model at /local/domain/$DOMID/image/device-model-pid

If a malicious guest did

xenstore-write /local/domain/26/image/device-model-pid 1

It is possible that in some circumstances, when a host admin later tries to kill the guest, it would in fact kill 'init' process in the host.

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

How reproducible: Always

Steps to Reproduce: 1. Inside a guest

#yum install xen # xenstore-write /local/domain/GUEST-DOMID/console/tty /i/am/the/evil/guest

2. On the host

xm console GUEST-NAME

Also various other checks Actual results: xenconsole: Could not open tty /i/am/the/evil/guest': No such file or directory

Expected results: xm console still works, and does not read data from untrusted areas.

Additional info:

Buffer overflow in the backend framebuffer of XenSource Xen Para-Virtualized Framebuffer (PVFB) Message 3.0 through 3.0.3 allows local users to cause a denial of service (SDL crash) and possibly execute arbitrary code via "bogus screen updates," related to missing validation of the "format of messages."

Buffer overflow in the backend of XenSource Xen Para Virtualized Frame Buffer (PVFB) 3.0 through 3.1.2 allows local users to cause a denial of service (crash) and possibly execute arbitrary code via a crafted description of a shared framebuffer.