Information
Advisory | XSA-251 |
Public release | 2017-12-12 11:35 |
Updated | 2018-01-06 16:14 |
Version | 3 |
CVE(s) | CVE-2017-17565 |
Title | improper bug check in x86 log-dirty handling |
Files
advisory-251.txt (signed advisory file)
xsa251.meta
xsa251.patch
xsa251-4.5.patch
xsa251-4.8.patch
Advisory
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2017-17565 / XSA-251
version 3
improper bug check in x86 log-dirty handling
UPDATES IN VERSION 3
====================
CVE assigned.
ISSUE DESCRIPTION
=================
Memory sharing, available to x86 HVM guests only, uses a special value
in the global machine to physical address translation table (M2P). PV
guests have full control over M2P entries corresponding to pages they
own. A bug check (specifically, an assertion that an M2P entry is not
the special "shared" indicator) was insufficiently qualified, and as a
consequence is triggerable by PV guests in log-dirty mode
(e.g. because of being live migrated).
IMPACT
======
A malicious or buggy PV guest may cause a hypervisor crash, resulting in
a Denial of Service (DoS) affecting the entire host.
VULNERABLE SYSTEMS
==================
Xen versions 4.0 and later are affected. Xen versions 3.4 and earlier
are not affected.
Only x86 systems are vulnerable. ARM systems are not vulnerable.
x86 HVM guests cannot exploit this vulnerability.
Only x86 PV guests can exploit this vulnerability, and only when being
run in shadow mode. PV guests are typically run in shadow mode for live
migration, as well as for features like VM snapshot.
Note that save / restore does *not* use shadow mode, and so does not
expose this vulnerability. Some downstreams also include a "non-live
migration" feature, which also does not use shadow mode (and thus does
not expose this vulnerability).
MITIGATION
==========
Running only HVM guests avoids the vulnerability.
Avoiding live migration of x86 PV guests also avoids the vulnerability.
CREDITS
=======
This issue was discovered by Jan Beulich of SUSE.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa251.patch xen-unstable, Xen 4.9.x
xsa251-4.8.patch Xen 4.8.x, Xen 4.7.x, Xen 4.6.x
xsa251-4.5.patch Xen 4.5.x
$ sha256sum xsa251*
152cf5c88c3e441af01cdf5749877cabb6ab961afee9f29ae3077e725b703aa2 xsa251.meta
0dfbcfe459f051abb571d3fbedbe9760a4c6cd540ab5d525627050e3eeb9234e xsa251.patch
345a6e004e0d0d89c7fc8db55d48d68f53402a521bd1aa3cb4168043e1ae5673 xsa251-4.5.patch
f8cecf013a3628038e0a4566778852a560b25a1ce2f3872a989087ab2fc9a913 xsa251-4.8.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
iQEcBAEBCAAGBQJaUPXgAAoJEIP+FMlX6CvZd1wIALEfYx5UtaqCZrUpgc+TwN8u
Fg+huu3hE/YDVMY5IHueUsVU4WMk7/XJL/hXxf0+Dr01M5nVUbs1cJIB7Gqch37n
Vo6JMHM0XHUEQB/Ctxn/nRi1PfAjvz/nSrCcRacIeTZNHm6Wzc7qtlOyjDWgbVwJ
JvboCmK0ueGTVd3RIGvxM0jDzWqRuObf4KLaCWka3rqZvYzZJJOGAO9C8HdZn9Bc
pMIV79QuYySvJm9rdNUSno2s19DJNNCOki2/HpU1CHv/b8May82fE+qZH5XexsnZ
x2d1G8cvsK0L+auqQO/U3Rln9B2MWp9hn2cVGP2DbLq/AO2yir5b7d/CPzqhIag=
=O0vJ
-----END PGP SIGNATURE-----
Xenproject.org Security Team