ISSUE DESCRIPTION
=================

Various parts of libxl device-handling code inappropriately use
information from (partially) guest controlled areas of xenstore
(principally the frontend directory
/local/domain/GUEST/device/TYPE/DEVID,
henceforth referred to as FE).  The problems vary by device type:

For all devices other than the main PV console, the guest can write
FE/backend to point to the backend of a device belonging to a
different guest.  On subsequent domain removal (for example, by guest
reboot or migration) libxl uses this value with insufficient checks,
allowing libxl to be tricked into tearing down devices belonging to
other guests.

For almost all device types (all devices except consoles and
channels), the guest has the ability to completely remove FE.  This
will normally result in the virtual device no longer functioning
(which is bad for the guest and an outcome the guest could achieve
anyway).  But it will also cause the device not to appear in lists of
devices, and prevent the device being properly torn down during domain
destruction (including guest reboot and migration).  When such a
malicious domain is shut down, the host resources associated with the
manipulated devices may remain in use: for example, disk and nic
hotplug teardown scripts will not be run.  For resources allocated in
an manner which excludes some other accesses, this can prevent the
operation of that other software on the host (for example, it can
prevent management operations on the underlying objects); for
resources are allocated in a nonexclusive manner, the guest can
consume new resources with each successive guest boot, eventually
exhausting capacity.

For almost all device types the backend xenstore path and domid
returned to libxl's caller during query functions servicing the domain
are read from a guest-controlled part of xenstore.  This means that a
guest can cause incorrect displays in tools like xl, and possibly
cause maloperation by higher-level domain management systems.

For all device types, libxl would read the guest-writeable FE/backend
node to find the xenstore path to the backend.  A guest could write a
bad value, which would (mostly) be detected by libxl but would cause
libxl operations (including informational functions) to fail.

For consoles, vtpm and channel devices, libxl would use FE/backend
without checking, to discover important information about the device.
For vtpm devices, this means guest can manipulate the
apparently-configured uuid.  For channel devices, the guest can
manipulate the apparently-configured channel name.

For channel devices, the guest can trick console attachment tools in
the backend domain into connecting to arbitrary wrong paths on the
backend domain filesystem.

IMPACT
======

A malicious guest administrator can cause denial of service to other
guests.

A malicious guest administrator can confuse and/or deny service to
management facilities.

A malicious guest administrator of a guest configured with channel
devices may be able to escalate their privilege to that of the backend
domain (i.e., normally, to that of the host).

VULNERABLE SYSTEMS
==================

Xen systems using libxl based toolstacks (for example xl or libvirt
with the libxl driver) are vulnerable to denial of service to guests
and administrators.

Xen systems with guests configured with channel devices are possibly
vulnerable to privilege escalation by those guests.

(Channel devices are be configured with "channel=" in the xl domain
configuration file.  See
http://xenbits.xen.org/docs/4.6-testing/misc/channel.txt
for more information.)

MITIGATION
==========

Disabling channel devices in applicable guests will reduce the
impact of the vulnerability.

Limiting the frequency with which a guest is able to reboot, or
limiting or eliminating a guest's ability to be granted exclusive
access to host resources, will reduce the resource exhaustion impact.

External References:

http://xenbits.xen.org/xsa/advisory-175.html

Acknowledgements:

Name: the Xen project