Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 583464 (CVE-2016-4962) - <app-emulation/xen{,-tools}-4.6.1-r4: Unsanitised guest input in libxl device handling code XSA-175 (CVE-2016-4962)
Summary: <app-emulation/xen{,-tools}-4.6.1-r4: Unsanitised guest input in libxl device...
Status: RESOLVED FIXED
Alias: CVE-2016-4962
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: C3 [noglsa cve]
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-19 02:53 UTC by Yury German
Modified: 2016-11-22 03:36 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yury German Gentoo Infrastructure gentoo-dev Security 2016-05-19 02:53:20 UTC
.
Comment 1 Yury German Gentoo Infrastructure gentoo-dev Security 2016-05-19 02:56:20 UTC
                    Xen Security Advisory XSA-175
                              version 2

         Unsanitised guest input in libxl device handling code

              *** EMBARGOED UNTIL 2016-06-02 12:00 UTC ***

UPDATES IN VERSION 2
====================

Include draft of backports to 4.6.  These have been run through a
private instance of osstest, but please test them and report issues as
soon as possible.

NB that vusb was introduced in 4.7, so the vusb-related patch has not
been backported to 4.6.

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.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa175-unstable/*.patch           xen-unstable
xsa175-4.6/*.patch                xen-4.6

$ sha256sum xsa175-*/*
473fdf33f6f26c0655b504e2cc384c20904bcdd713fbacc4236f499a0a6f8ac3  xsa175-unstable/0001-libxl-Record-backend-frontend-paths-in-libxl-DOMID.patch
531b2233581d847f26eeffc5fa7c1428a2f42336aed7943165da881003d4be90  xsa175-unstable/0002-libxl-Provide-libxl__backendpath_parse_domid.patch
cfb45654444a95e80a2b9608448b1092f407b9a9d52436ce49c45978e5e8c310  xsa175-unstable/0003-libxl-Do-not-trust-frontend-in-libxl__devices_destro.patch
361cc95707bba9b1801e4972016ca61ab6d8103f93b0141758112eaa61d9113d  xsa175-unstable/0004-libxl-Do-not-trust-frontend-in-libxl__device_nextid.patch
f21e63a17728e638d4e33e074e5a35fa9eb18f13c0051d9bef0d7849b60de649  xsa175-unstable/0005-libxl-Do-not-trust-frontend-for-disk-eject-event.patch
0fe8d5e65103a9fc2b54692726ab66ddf4004a641e5b6730ee97c7b1621d6543  xsa175-unstable/0006-libxl-Do-not-trust-frontend-for-disk-in-getinfo.patch
dd06e96c10c51829d7489c72d2560a9bbd12dbd727a0bb492810b334d0623296  xsa175-unstable/0007-libxl-Do-not-trust-frontend-for-vtpm-list.patch
64e56d387e418082dbd0088a012e263abda0d452a77ff7c2273cb7425d45fc60  xsa175-unstable/0008-libxl-Do-not-trust-frontend-for-vtpm-in-getinfo.patch
6e3b59ac930d5210032bf1015782c14bc94881e8734e451e3d5f0c3e794f4d34  xsa175-unstable/0009-libxl-Do-not-trust-frontend-for-nic-in-libxl_devid_t.patch
2c9a23f859bf8ecd1800089ca7f9032b24311a90c4cfe38f2a26f5ee6a8443c6  xsa175-unstable/0010-libxl-Do-not-trust-frontend-for-nic-in-getinfo.patch
43d39d6544893c76a91c056543d46a0bfa32cf2891d234815b6a3d43d87fa5ef  xsa175-unstable/0011-libxl-Do-not-trust-frontend-for-channel-in-list.patch
82da838f3daff7f225426b6572e7f7577e821f3546bb1d2ddafd72fbc8839a0d  xsa175-unstable/0012-libxl-Do-not-trust-frontend-for-channel-in-getinfo.patch
e732be8fae0d7c7de487a6a7ab919f2b91005067ce2dcf7083195fb74e2943de  xsa175-unstable/0013-libxl-Do-not-trust-frontend-for-vusb.patch
c44dcbf52358b8747c922257cad3d03cc056ecc03ecd396e50f6b3f6d1cea798  xsa175-4.6/0001-libxl-Record-backend-frontend-paths-in-libxl-DOMID.patch
fd11a983dc1f125901daaa9c9019edb46c3d16a9371399a6e9c9ef4a23b54276  xsa175-4.6/0002-libxl-Provide-libxl__backendpath_parse_domid.patch
f50f7156dc5595d1d1839c225ac8c4bd767511bc6ce4aec5f60b9ab207ea7631  xsa175-4.6/0003-libxl-Do-not-trust-frontend-in-libxl__devices_destro.patch
09b2faa98ec3db11142c17fd4d9e055505f4552ff43e48da4d30ebcbf6b929f4  xsa175-4.6/0004-libxl-Do-not-trust-frontend-in-libxl__device_nextid.patch
4fa05ee839da5bae49e4b403a2d13da802e10f7aa586007da89e73c6fd6719b7  xsa175-4.6/0005-libxl-Do-not-trust-frontend-for-disk-eject-event.patch
92f423b541e9447f0bf37a83bbece2cfe198b1db33ca02cd3f6ca17bad203f2f  xsa175-4.6/0006-libxl-Do-not-trust-frontend-for-disk-in-getinfo.patch
97fb68eda21ab0151e6e240ddde34da0da0e8f11ea448f4603d7ef2326acda70  xsa175-4.6/0007-libxl-Do-not-trust-frontend-for-vtpm-list.patch
9cde88602e13c2964307fa1bc5b1601dc6796d4b9d9b9e49898e1d13470c71ab  xsa175-4.6/0008-libxl-Do-not-trust-frontend-for-vtpm-in-getinfo.patch
69a19ee15ad266e391b4356a2f6ad3442a905cd06441921ae4e2c2778823f8ae  xsa175-4.6/0009-libxl-Do-not-trust-frontend-for-nic-in-libxl_devid_t.patch
51fadcafa1549201d6dd4eda9c3f8b9d2c7cad6851f2aafe3569ec3980c5a256  xsa175-4.6/0010-libxl-Do-not-trust-frontend-for-nic-in-getinfo.patch
dc925af06451392d87f8750b3be2ad60b95be107f2534391063732f1e1b5109a  xsa175-4.6/0011-libxl-Do-not-trust-frontend-for-channel-in-list.patch
57211890bf71f7648f5b3f7a88f79fddb7d3077eb3a1bc3cbd6f910fa324dfd1  xsa175-4.6/0012-libxl-Do-not-trust-frontend-for-channel-in-getinfo.patch
$
Comment 2 Yury German Gentoo Infrastructure gentoo-dev Security 2016-05-19 02:56:56 UTC
Files forwarded to Maintainer in an encrypted channel.
Comment 3 Yixun Lan gentoo-dev 2016-06-07 05:48:39 UTC
commit f22d36084c5cdabb599a38b8e1e26832c4bacd94
Author: Yixun Lan <dlan@gentoo.org>
Date:   Tue Jun 7 13:38:13 2016 +0800

    app-emulation/xen-tools: fix XSA-175,178 bug
    
    also include a few non-security upstream fixes
    
    Gentoo-Bug: 583464, XSA-175
    Gentoo-Bug: 583466, XSA-178
    
    Package-Manager: portage-2.3.0_rc1
Comment 4 Thomas Deutschmann gentoo-dev Security 2016-11-21 13:21:33 UTC
@ Security: Please vote!
Comment 5 GLSAMaker/CVETool Bot gentoo-dev 2016-11-22 03:33:19 UTC
CVE-2016-4962 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-4962):
  The libxl device-handling in Xen 4.6.x and earlier allows local OS guest
  administrators to cause a denial of service (resource consumption or
  management facility confusion) or gain host OS privileges by manipulating
  information in guest controlled areas of xenstore.
Comment 6 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-11-22 03:36:16 UTC
GLSA Vote: No