Information

Files

Advisory

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2016-4963 / XSA-178
                              version 4

       Unsanitised driver domain input in libxl device handling

UPDATES IN VERSION 4
====================

Clarify that issue goes back as far as driver domain suppoprt.

Mention backports.

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

libxl's device-handling code freely uses and trusts information from
the backend directories in xenstore.

The backend domain (driver domain) can store bogus data in the
backend, causing libxl's enquiry functions to fail, confusing
management tools.

A driver domain can also remove its backend directory from xenstore
entirely, preventing the device from showing up in device listings and
preventing it from being removed and replaced.

A driver domain can cause libxl to generate disk eject events for
disks for which the driver domain is not responsible.

IMPACT
======

A malicious driver domain can deny service to management tools.

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

This vulnerability is only applicable to systems which are using
driver domains, and then only where the driver domain is not intended
to be fully trusted with respect to the host.

Such Xen systems using libxl based toolstacks (for example xl or
libvirt with the libxl driver) are vulnerable.

Note that even with this vulnerability a driver domain based system is
better from a security point of view, than a system where devices are
provided directly by dom0.  Users and vendors of systems using driver
domains should not change their configuration.

All versions of libxl which support the relevant driver domains are
vulnerable.

MITIGATION
==========

No mitigation is available.

CREDITS
=======

This issue was discovered by Wei Liu from Citrix.

RESOLUTION
==========

Applying the appropriate attached patch set from XSA-175, plus the
appropriate attached patch set below, resolves this issue.

xsa178-unstable/*.patch           xen-unstable

For earlier Xen releases, patches have been prepared and applied to
the staging-4.X branches, back to Xen 4.3.  The Xen Project CI system,
osstest, is currently doing basic functional testing of these
backports.  However, driver domains are not tested by osstest, nor
have they been tested by the Xen Project Security Team.  The patches
can be found in xen.git:
  xen.git commits 2805844bf20e..562ecb389444    Xen 4.6
  xen.git commits 6265a6fc7f58..d8ac67eff778    Xen 4.5
  xen.git commits 551948806424..a0b99aba04d9    Xen 4.4
  xen.git commits 5811d6bdf5bb..08ea21f2361d    Xen 4.3
See:
  http://xenbits.xen.org/gitweb/?p=xen.git;a=summary
  git://xenbits.xen.org/xen.git
  http://xenbits.xen.org/git-http/xen.git

$ sha256sum xsa178-*/*
fd6a1f858d44f618a4e792553598005871f63d12e718bc9b5477d14bf0113386  xsa178-unstable/0001-libxl-Make-copy-of-every-xs-backend-in-libxl-in-_gen.patch
ee6cf66ad385203c49d9b030959715fb885a250aa36b85080e6985a603bb1ddb  xsa178-unstable/0002-libxl-Do-not-trust-backend-in-libxl__device_exists.patch
ea29cf28609c2d467fb7a620601af7bf434b098a7554dada956f11ed50c1b895  xsa178-unstable/0003-libxl-Do-not-trust-backend-for-vtpm-in-getinfo-excep.patch
a2abc4308d9a18f49a02e6ca8ba913d4d9890867b7816dcc19b548836b65af6c  xsa178-unstable/0004-libxl-Do-not-trust-backend-for-vtpm-in-getinfo-uuid.patch
2884e6566c59ae95792d4282e174c6b3d201c1e006b9e0ab57fbaad2b62ecfb9  xsa178-unstable/0005-libxl-cdrom-eject-and-insert-write-to-libxl.patch
d6ac82211d056a386d18b8296a6a1f2e8a65e8156594595b9c34a3a377f1cf98  xsa178-unstable/0006-libxl-Do-not-trust-backend-for-disk-eject-vdev.patch
4c8bb7bee3b624b02796afdfa0157ea1dc49a7f54f34912f992bae201b6bfe40  xsa178-unstable/0007-libxl-Do-not-trust-backend-for-disk-fix-driver-domai.patch
556b14e8783ddd7ad0cb9a561ca43a40b37ccb27cd56337e7714ac0f796ce21b  xsa178-unstable/0008-libxl-Do-not-trust-backend-for-disk-in-getinfo.patch
b51aaa8cca1f367ae51ffb65240831617d4cab4a3fa6d0a2d42728e99ee8cee8  xsa178-unstable/0009-libxl-Do-not-trust-backend-for-cdrom-insert.patch
3ef493e6bda2d2b96a89cf18b55d43fbdb84a2cd5c10c88f04299434c629ba2b  xsa178-unstable/0010-libxl-Do-not-trust-backend-for-channel-in-getinfo.patch
da4db890c9e73fca006bc381f2208f9bff0fc35990c4dd51d59999db27072d33  xsa178-unstable/0011-libxl-Rename-libxl__device_-nic-channel-_from_xs_be-.patch
ae8b043a83cc35beee2205ab621b6f5bc6543f6d4dcdc06c97e07b1a17ca94bf  xsa178-unstable/0012-libxl-Rename-READ_BACKEND-to-READ_LIBXLDEV.patch
936c44de9a344b0634b7bff4f5b3cf9c034a0080e87d267e7a84683a967d1bff  xsa178-unstable/0013-libxl-Have-READ_LIBXLDEV-use-libxl_path-rather-than-.patch
3b65a3140387651cf2ed1bcf8668efecd58fbd274a62a03d785c269b55bea8fe  xsa178-unstable/0014-libxl-Do-not-trust-backend-in-nic-getinfo.patch
6d009153b98fd58f316efa4f39c821cf609b54184726e15f887947321610ed14  xsa178-unstable/0015-libxl-Do-not-trust-backend-for-nic-in-devid_to_devic.patch
3105c062bb2017681f47499e2dd2f6cd2996539068f216a5af7d6143bc726eda  xsa178-unstable/0016-libxl-Do-not-trust-backend-for-nic-in-list.patch
97961ce38d8d77e9d91ee85052fd33e04d19f45e5ddfec61f82dc9c8a78158ea  xsa178-unstable/0017-libxl-Do-not-trust-backend-in-channel-list.patch
6ebb611501b66dca66259d3a790e30ae6d892eb27c6d06577d8f399d619c286b  xsa178-unstable/0018-libxl-Do-not-trust-backend-for-vusb.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

HOWEVER note that deployment of the patches for XSA-175 (which are a
prerequisite for the patches for XSA-178) is restricted.  See
XSA-175's `Deployment During Embargo' section for details.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJXVasRAAoJEIP+FMlX6CvZW9EIAJZjfuCUa2pbO8oOGsjqvlSe
J9scuF2hHiQB4ii04ORwqtgaE0TmttKQMTL8XAZBvp2f5F1MJsXIlteD9kBFApEA
5lzxvVie+sP8qUj5LvZUkby1tlohWiJfylx8dOQTvU6vkzYIAS+z2dt30+KpNLL5
P7bfJEcHBMJw33PApTQpVe9NRfQox6mVxDEG+1O6W7DsX0uSH8wLh21o355kMYxO
3+ym9GXKuHVI3FFHjEtTTEbpM2s7KlSApreAEvQIe68KKjkjFIadRe+4JCrAfqg3
F8pE+VI2eH3ZMGrf52Mhko9PR9DjUc8oQiTSp/H5a10mhTaMfePDU1zADcsZmmw=
=ArWH
-----END PGP SIGNATURE-----