[v2.7] Xen Security Advisory 57 - libxl allows guest write access to sensitive console related xenstore keys (CVE-2013-2211 )
ISSUE DESCRIPTION
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator to change values in xenstore which the host later relies
on being implicitly trusted.
IMPACT
A malicious guest administrator can read and write any files in the
host filesystem which are accessible to the user id running the
xenconsole client binary. This may be the user id of a host
administrator who connects to the guest’s console or the user id of
any self service mechanism provided to guest administrators by the
host provider.
As well as reading and writing files an attacker with access to an HVM
guest can cause any PV or serial consoles to be connected to a variety
of network resources (sockets, udp connections) or other end points
(fifo, pipes) in the host file filesystem according to the privileges
granted to the qemu device model for that guest.
A malicious guest administrator can also redirect the VNC console
port of the guest to another port on the host. This may expose the VNC
port of other guests or of other firewalled services to an attack.
VULNERABLE SYSTEMS
All systems which use libxl as part of the toolstack are vulnerable.
libxl is present in Xen versions 4.0 onwards.
The major consumer of libxl functionality is the xl toolstack which
became the default in Xen 4.2.
In addition to this libvirt can optionally make use of libxl. This can
be queried with
# virsh version
Which will report “xenlight” if libxl is in use. libvirt currently
prefers the xend backend if xend is running.
The xend and xapi toolstacks do not currently use libxl.
MITIGATION
Host administrators can start a domain paused and manually correct the
xenstore permissions of the relevant nodes.
A domain can be started in the paused state with xl by using
# xl create -p
A domain’s domid can then be determined with:
# xl domid
If using libvirt then virsh can be used instead:
# virsh start —paused
# virsh domid
For a domain $DOMID the following command will recursively correct the
permissions for the primary PV console:
# xenstore-chmod -r /local/domain/DOMID/console n0 r
DOMID
If the domain uses a device model stubdomain then it will also be
necessary to fix the permissions for the stubdomain. The stubdomain is
named “-dm”. Assuming its domain ID is $DMDOM:
# xenstore-chmod -r /local/domain/DMDOM/console n0 r
DMDOM
In addition a stub domain has three secondary PV consoles which must
be
fixed, however in this case the “state” and “protocol” nodes along
with the device node itself should not be restricted. For each device
$D in [1,2,3]:
# xenstore-chmod -r /local/domain/DMDOM/device/console/
N n0 r$DMDOM
# xenstore-chmod /local/domain/DMDOM/device/console/
N/state n$DMDOM
r0
# xenstore-chmod /local/domain/DMDOM/device/console/
N/protocol
n$DMDOM r0
# xenstore-chmod /local/domain/DMDOM/device/console/
N n$DMDOM r0
The current permissions can be listed with
# xenstore-ls -fp
Once the permissions are fixed you may unpause the domain with
# xl unpause
or with virsh:
# virsh resume
The permissions can also be corrected on a live system if they are
then manually validated to be non-malicious.
See http://wiki.xen.org/wiki/XenBus\#Permissions for information on
the
permissions syntax.
RESOLUTION
Applying the appropriate attached patch resolves this issue.
xsa57-4.2.patch Xen 4.2.x
xsa57-4.1.patch Xen 4.1.x
xsa57-unstable.patch xen-unstable
$ sha256sum xsa57-*.patch
428a1d42f4314404cde339a78a59422bf4f0590c4d16ea8adc83425fe5eede3d
xsa57-4.1.patch
b6a5106848541972519cc529859d9ff3083c79367276c7031560fa4ce6f9f770
xsa57-4.2.patch
d329f56c30f7a4f91906658ea661234d2ca31b74ee68257bf009072999b3d3ef
xsa57-unstable.patch
(from redmine: issue id 2122, created on 2013-06-26, closed on 2013-07-03)
- Relations:
- parent #2117 (closed)
- Changesets:
- Revision 932f289c by Natanael Copa on 2013-06-26T11:48:01Z:
main/xen: fix xsa57 (CVE-2013-2211)
ref #2117
fixes #2122