Information

Files

Advisory

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2015-8338 / XSA-158
                              version 5

                long running memory operations on ARM

UPDATES IN VERSION 5
====================

Normalize version tags.

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

Certain HYPERVISOR_memory_op subops take page order inputs, with so far
insufficient enforcement of limits thereof. In particular, for all of
XENMEM_increase_reservation, XENMEM_populate_physmap, and
XENMEM_exchange the order was limited to 9 only for guests without
physical devices assigned. Guests with assigned devices were allowed up
to order 18 (x86) or 20 (ARM). XENMEM_decrease_reservation enforced
only the latter, higher limit uniformly on all kinds of guests.

All of these operations involve loops over individual pages (possibly
nested, with only the iteration count of the innermost loop being of
interest here), resulting in iteration counts of up to 1 million on
ARM. Total execution time of these operations obviously depends on
system speed, but have been measured to get into the seconds range.

IMPACT
======

A malicious guest administrator can cause a denial of service.
Specifically, prevent use of a physical CPU for a significant period.
Other attacks, namely privilege escalation, cannot be ruled out.

If a host watchdog (Xen or dom0) is in use, this can lead to a
watchdog timeout and consequently a reboot of the host.  If another,
innocent, guest, is configured with a watchdog, this issue can lead to
a reboot of such a guest.

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

All Xen versions supporting ARM are affected.

x86 versions of Xen are unaffected.

MITIGATION
==========

The vulnerability can be avoided if the guest kernel is controlled by
the host rather than guest administrator, provided that further steps
are taken to prevent the guest administrator from loading code into
the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege.  On
ARM, controlling the guest's kernel may involve locking down the
bootloader.

Exposure may be limited by not passing through physical devices to
untrusted guests.

(However, where device pass-through is being used to enhance security,
for example, by disaggregating device drivers, users should not change
their configuration: moving the drivers from a separate domain, to
dom0, does NOT mitigate this vulnerability.  Rather, it simply
recategorises the additional exposure, regarding it "as designed" and
therefore "not a bug".  Users and vendors of disaggregated systems
should not change their configuration.)

CREDITS
=======

This issue was discovered by Julien Grall of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

Note that the patches provided with previous versions of this advisory
had two problems:

 - The bounding for ordinary DomU and DomU with pass-through devices(s)
   was swapped.  This would result in non-pass-through domains being able
   to perform operations with larger than intended order.  In the default
   configuration this higher limit is not sufficient to reopen the
   security issue.  However, users of the new memop-max-order option
   may be vulnerable, depending on the limits they specify.

 - On 4.4 and earlier, the relevant patch does not compile on ARM.

The supplementary patch xsa158-fix.patch fixes these problems on all
listed versions.


In summary:

xsa158.patch, xsa158-fix.patch      xen-unstable, Xen 4.6.x, Xen 4.5.x
xsa158-4.4.patch, xsa158-fix.patch  Xen 4.4.x, Xen 4.3.x

$ sha256sum xsa158*
50d7431cbad8faa631e2057ddd795b880f79b96d126a0b83afef3eceacf0026d  xsa158.patch
54b538905e66227bf7f326006a7c322bdf35c76ad8600ff462e61d6e2eab6f04  xsa158-4.4.patch
ab37e320bceeccc81285a6a72b92ed1292b69ddd8da5af94276b4b5cca4a0441  xsa158-fix.patch
$

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

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


However deployment of the NO PASS-THROUGH partial MITIGATION is NOT
permitted (except where all the affected systems and VMs are
administered and used only by organisations which are members of the
Xen Project Security Issues Predisclosure List).  Specifically,
deployment on public cloud systems is NOT permitted.

This is because altering the set of devices observable in a guest in
connection with a security issue would be a user-visible change which
could lead to the rediscovery of the vulnerability.

Deployment of the mitigation is permitted only AFTER the embargo ends.


Also: 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-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmV8b/EMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZtJwIAJJ8Se1BdwzJfRwoQDbyy//pV/krFVHAw2bF9z5Y
Wqq4n+jLAn9v7+31nIobWbgRMmFLFAP2/e9jZLFu9b1s8pvmZzeUKmCNfMdcQV2I
o3SjUnvEpHm3qqY0O9R0JdtJAFvE45klKV5d7+KkTWt5cedr9ZQNms5SlHgzSS5w
Osj7LbTQyALGimp/8LrtV4tlmf6LO20tgPnVI/BcT0KCJTMcYtmYEkmOn1RSwiGv
1oaZCCn6DNGLiKUJuGL+FUSdNROWc2kS7FCWLGHWRCSyX7xmYVC/q2fmD2zPI4QH
zyPDofowV3DrgJyHDNkB5pDg+CQ4cQGypoGN2UZ+iSD1ZG0=
=iZpT
-----END PGP SIGNATURE-----