[<prev] [next>] [day] [month] [year] [list]
Message-Id: <E1Z31cd-0002ro-EG@xenbits.xen.org>
Date: Thu, 11 Jun 2015 12:30:15 +0000
From: Xen.org security team <security@....org>
To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org,
xen-users@...ts.xen.org, oss-security@...ts.openwall.com
CC: Xen.org security team <security@....org>
Subject: Xen Security Advisory 136 (CVE-2015-4164) - vulnerability in the
iret hypercall handler
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2015-4164 / XSA-136
version 3
vulnerability in the iret hypercall handler
UPDATES IN VERSION 3
====================
Public release.
Added email header syntax to patches, for e.g. git-am.
ISSUE DESCRIPTION
=================
A buggy loop in Xen's compat_iret() function iterates the wrong way
around a 32-bit index. Any 32-bit PV guest kernel can trigger this
vulnerability by attempting a hypercall_iret with EFLAGS.VM set.
Given the use of __get/put_user(), and that the virtual addresses in
question are contained within the lower canonical half, the guest
cannot clobber any hypervisor data. Instead, Xen will take up to 2^33
pagefaults, in sequence, effectively hanging the host.
IMPACT
======
Malicious guest administrators can cause a denial of service affecting
the whole system.
VULNERABLE SYSTEMS
==================
Only 64-bit x86 (ARCH=x86_64) builds of Xen are vulnerable. 32-bit
builds (ARCH=x86_32) (necessarily of Xen 4.2 or earlier), are not
affected.
Xen versions 3.1 or later are vulnerable.
ARM systems are not vulnerable.
Only 32-bit PV guests can exploit the vulnerability.
MITIGATION
==========
Systems which only need to run 32-bit guests and are running Xen 4.2
or earlier can avoid the vulnerability by using a 32-bit build of Xen
instead of a 64-bit build. (The dom0 operating system would have to
be 32-bit too.)
If the boot process and kernel for the guest can be controlled,
forcing it to use a 64-bit kernel will avoid the vulnerability.
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the attached patch resolves this issue.
$ sha256sum xsa136*.patch
b54a71cf41d333345a9b8fd5f3f1aa644000a24e20343b54e5a41cd51d14af04 xsa136.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.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJVeX73AAoJEIP+FMlX6CvZwMsIAIkHonCdvStKAJZ6WpWFaAeo
dgEBdQ0tHCkuEu3PNBNy0YPklBdATwQNOjt+XZj6qDJv0HvBykZNoam0E9UCqH85
BYS0ASvjxUQrd61PrTWGmdh9XKMj2FJRGmpumr4XnNzcOalwOLuwUmfIauEIQaMy
0yxrgcoWk2C3oWIO54m/vObwdttNlbGInrBK1bDyrOtAX0UrHByLU7dPCe0TlE5l
IIa7QH/FcKLp7+RhxIEOQGBvuMSnw2bcXSqCIwleGo1RpnzcA/N1P+8FNs9rWmm/
toGYLeaQus8h9fEe51zGKOTQrf+WWuKhSjwkxSFr/HEH6xHEl+oCYvwlyB5CviM=
=yJg0
-----END PGP SIGNATURE-----
Download attachment "xsa136.patch" of type "application/octet-stream" (650 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
