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----- [ CONTENT OF TYPE application/octet-stream SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ