Information

Files

Advisory

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

            Xen Security Advisory CVE-2017-17045 / XSA-247
                              version 3

                 Missing p2m error checking in PoD code

UPDATES IN VERSION 3
====================

CVE assigned.

Fixed "Reported-by" tags in patch commit messages.

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

Certain actions require modification of entries in a guest's P2M
(Physical-to-Machine) table.  When large pages are in use for this
table, such an operation may incur a memory allocation (to replace a
large mapping with individual smaller ones).  If this allocation
fails, the p2m_set_entry() function will return an error.

Unfortunately, several places in the populate-on-demand code don't
check the return value of p2m_set_entry() to see if it succeeded.

In some cases, the operation was meant to remove an entry from the p2m
table.  If this removal fails, a malicious guest may engineer that the
page be returned to the Xen free list, making it available to be
allocated to another domain, while it retains a writable mapping to
the page.

In other cases, the operation was meant to remove special
populate-on-demand entries; if this removal fails, the internal
accounting becomes inconsistent and may eventually hit a BUG().

The allocation involved comes from a separate pool of memory created
when the domain is created; under normal operating conditions it never
fails, but a malicious guest may be able to engineer situations where
this pool is exhausted.

IMPACT
======

An unprivileged guest can retain a writable mapping of freed memory.
Depending on how this page is used, it could result in either an
information leak, or full privilege escalation.

Alternatively, an unprivileged guest can cause Xen to hit a BUG(),
causing a clean crash - ie, host-wide denial-of-service (DoS).

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

All systems from Xen 3.4 are vulnerable.

Only x86 systems are vulnerable.  ARM is not vulnerable.

x86 PV VMs cannot leverage the vulnerability.

Only systems with 2MiB or 1GiB HAP pages enabled are vulnerable.

The vulnerability is largely restricted to HVM guests which have been
constructed in Populate-on-Demand mode (i.e. with memory < maxmem):

x86 HVM domains without PoD (i.e. started with memory == maxmem, or
without mentioning "maxmem" in the guest config file) also cannot
leverage the vulnerability, in recent enough Xen versions:
  4.8.x and later: all versions safe if PoD not configured
  4.7.x: 4.7.1 and later safe if PoD not configured
  4.6.x: 4.6.4 and later safe if PoD not configured
  4.5.x: 4.5.4 and later safe if PoD not configured
  4.4.x and earlier: all versions vulnerable even if PoD not configured

The commit required to prevent this vulnerability when PoD
not configured is 2a99aa99fc84a45f505f84802af56b006d14c52e
  xen/physmap: Do not permit a guest to populate PoD pages for itself
and the corresponding backports.

MITIGATION
==========

Running only PV guests will avoid this issue.

Running HVM guests only in non-PoD mode (maxmem == memory) will also
avoid this issue.  NOTE: In older releases of Xen, an HVM guest can
create PoD entries itself; so this mitigation will not be effective.

Specifying "hap_1gb=0 hap_2mb=0" on the hypervisor command line will
also avoid the vulnerability.

Alternatively, running all x86 HVM guests in shadow mode will also
avoid this vulnerability.  (For example, by specifying "hap=0" in the
xl domain configuration file.)

CREDITS
=======

This issue was discovered by George Dunlap of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa247/*.patch           xen-unstable
xsa247-4.9/*.patch       Xen 4.9.x
xsa247-4.8/*.patch       Xen 4.8.x
xsa247-4.7/*.patch       Xen 4.7.x
xsa247-4.6/*.patch       Xen 4.6.x
xsa247-4.5/*.patch       Xen 4.5.x

$ sha256sum xsa247* xsa247*/*
e8fc454c35f429ab60b94c0e812f86fd2b3b37edfff2bfdcc13a7e13ebc2efbe  xsa247.meta
3a8c0e02e9c94f68119f21a334ef70c409b71270c7de223d7d9163dbc1cfa286  xsa247-4.5/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch
6851ec78da2e91b03c8f3016311d32354a4dacf99ad20ea4f5dc1ed493d42a60  xsa247-4.5/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch
dce7e6c1961a85f59d20a3a98ea02d677a4956c3caf5273ea0b890d977cda3e5  xsa247-4.6/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch
110de2762531654b77fc38e4f2ee0bae76233e59557c6f6190e839065f9563cc  xsa247-4.6/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch
d149342e4d40dfb550f8af6d05cd20a34889d64fb33f967fe77cf89b4ea8504a  xsa247-4.7/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch
3c8a7bfdb408af0224cf6f5471b0fd9dd1a9a1ded7207e427b02268ca2906aa6  xsa247-4.7/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch
7ddbd99a30dcddc9a4e0dc7e2f4cfa63abb6237c6d9a706b729cf9df5f34b869  xsa247-4.8/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch
4574e27bb76d6dbb357b4dd8efa5fbbbffa69d17ea9c8f8330d3ef19f6cb3fce  xsa247-4.8/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch
2d0656e84be3b8eb828c199463c5532bddd16cf6e1159ce512a304ef85359422  xsa247-4.9/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch
f7429ae9fc9934d3a91aa6f3b9d2dc7a7e464128e4e2a8a71e7c8f26affdb731  xsa247-4.9/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch
024bce64257936048dff6cd66a0ba3212985cad42e78357a1c3513873099ebe2  xsa247/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch
32bb016003d7c37452222cacf22e74b4d29a227d6a808ae89c83293a2bd12f40  xsa247/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.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, with ONE exception:

Removing the ability to boot in populate-on-demand mode is NOT
permitted during the embargo on public cloud systems.  This is because
doing so might alert attackers to the nature of the vulnerability.
Deployment of this mitigation is permitted only AFTER the embargo
ends.

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

iQEcBAEBCAAGBQJaH/KPAAoJEIP+FMlX6CvZXrkH/AyVeBsY/MhMmPp7lfV9no52
FHQJF84UDrVDuYeQGVLbTcpXW+3ndEnLrg7Y2N6r6be1qn/KSKLtRO1gh+4mpRg4
n/bBKjldHTsVtr2lb51w6cd0AnibqP+9aSdT5qfselBVpwPBIuDsmny7ZQQnhZuN
CwRiKp8uNQ/RNxZHPOZ0k5FmugKQcysj0kSjtNvP+11Fk2b8tJP5o4tMozP/+Umu
kv9YAp5WxqqJUHtb25Abf7pszgmp72a19ajvUZK0TPNTajKbQBnBNEoC+GoocFjV
eu1iVOxduinIoCjNE/67GXQWajsF6ANnWz+dka306C4BS5WXWOWpMbdaAuLCq7Q=
=wtMZ
-----END PGP SIGNATURE-----