Information

Files

Advisory

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

            Xen Security Advisory CVE-2017-14318 / XSA-232
                               version 4

                     Missing check for grant table

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

Added metadata file

Public release.

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

The function `__gnttab_cache_flush` handles GNTTABOP_cache_flush grant
table operations. It checks to see if the calling domain is the owner
of the page that is to be operated on. If it is not, the owner's grant
table is checked to see if a grant mapping to the calling domain
exists for the page in question.

However, the function does not check to see if the owning domain
actually has a grant table or not. Some special domains, such as
`DOMID_XEN`, `DOMID_IO` and `DOMID_COW` are created without grant
tables. Hence, if __gnttab_cache_flush operates on a page owned by
these special domains, it will attempt to dereference a null pointer
in the domain struct.


IMPACT
======

The guest can get Xen to dereference a NULL pointer.

For ARM guests and x86 PV guests on systems with SMAP enabled, this will
cause a host crash (denial-of-service).

For x86 PV guests on systems without SMAP enabled, an attacker can map
a crafted grant structure at virtual address 0.  This can be leveraged
to increment an arbitrary virtual address, which can then probably be
leveraged into a full privilege escalation.


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

All versions of Xen since Xen 4.5 are vulnerable.

x86 HVM guests do not expose the vulnerability.

ARM guests and x86 PV guests on systems with SMAP enabled are only
vulnerable to a Denial-of-Service (host crash).

x86 PV guests on systems without SMAP running are vulnerable to a
privilege escalation.

MITIGATION
==========

Hardware supporting Supervisor Mode Access Prevention (Intel Broadwell,
AMD Zen) can mitigate the privilege escalation to a DoS.

CREDITS
=======

This issue was discovered by Matthew Daley.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa232.patch           xen-unstable, 4.9, 4.8, 4.7, 4.6, 4.5

$ sha256sum xsa232*
b193a711d013fe14556610ef3e703585164fdfc437c3a32a717c419e7a5afab2  xsa232.meta
5068a78293daa58557c30c95141b775becfb650de6a5eda0d82a4a321ced551c  xsa232.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.

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

iQEcBAEBCAAGBQJZt80FAAoJEIP+FMlX6CvZjCcH/0arWvHYjB/Zrnu9dMEjbfW8
ydFwwHm0foHY7ALp/RDazJjsNBDyt7iol0Z1Kv5wgxt+iLvgCuqVokkg80eoI6ku
TYkytzWsZOw1NOJQJ2nH7v5kW76qXceMAByrWZOm09xfFQ2hhGthz8IMwfyAhWc/
GtbsK4K3k2hEp2Uh1yhvT0m2pKvB1190MfNzsKeYIoAlYnDKQu1BB93NTkIlKypz
TgVfvm/1M6F/nnsekipFbGJ6/v7TEi0YqSm6uOudlbUSj0DTZYU5smBizfGwA8Ih
D5ROdlqfRsXsXiUdu/HAT/IB9r9knZpicQQPPmwYPhyB+Fn8UCQei3Z+pRYzGYI=
=aOmL
-----END PGP SIGNATURE-----