Date: Tue, 12 Aug 2014 13:03:30 +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 102 (CVE-2014-5147) - Flaws in handling traps from 32-bit userspace on 64-bit ARM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2014-5147 / XSA-102 version 3 Flaws in handling traps from 32-bit userspace on 64-bit ARM UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= When handling a trap from guest mode on ARM, Xen asserts that the current guest mode must match the domain address width. This assertion is false when a guest takes a trap from a 32-bit userspace running on a 64-bit kernel in a 64-bit domain. IMPACT ====== Any user in a guest which is running a 64-bit kernel who is able to spawn a 32-bit process can crash the host. I.e. an unprivileged guest user can cause host-wide denial of service. VULNERABLE SYSTEMS ================== 32-bit ARM systems and and X86 systems are not vulnerable. 64-bit ARM systems which support 32-bit userspace are vulnerable. Not all 64-bit ARM CPUs support 32-bit userspace in the actual CPU hardware. Systems without that hardware support are not vulnerable. Also, not all 64-bit ARM guest kernels have support for 32-bit userspace. Systems without that kernel support are vulnerable to a malicious guest administrator, but not to an unprivileged guest user. MITIGATION ========== On systems where the guest kernel is controlled by the host rather than guest administrator, running only 32-bit kernels. On systems where the guest kernel is controlled by the host rather than guest administrator, running 64-bit kernels with support for 32-bit userspace disabled (e.g CONFIG_COMPAT=n under Linux) will prevent untrusted guest users from exploting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS ======= This issue was reported as a bug by Riku Voipio, discovered via Linaro's LAVA testing and was diagnosed as a security issue by Ian Campbell. RESOLUTION ========== Applying the appropriate attached patches resolves these security issues. xsa102-unstable-*.patch xen-unstable xsa102-4.4-*.patch Xen 4.4.x $ sha256sum xsa102*.patch a5beb5c552e5bffe3e115905c478d6699c35df1d8721f8d6681099c38a974091 xsa102-4.4-01.patch 9f04ecda4dd9e31360daa27d87588d6017d866a97b84566241097def0af86a63 xsa102-4.4-02.patch a9860803ed5ed57bdc3ac94cdc924618b19e805b7f6a87bf9c1a9ea4b627281a xsa102-4.4-03.patch 7d0b5e05e5915c6c2d83590ba9acab0acfd1eba986a65a20ba69cf2c3394e062 xsa102-unstable-01.patch 7d5cf339a3f8c98b3e06852f845a2305df3f8ce195d243ee22d6783bb6904d60 xsa102-unstable-02.patch 3ca7b0632af36cc72ba59ed1822bcaebf2363f150435348265d1ade25e21bf90 xsa102-unstable-03.patch $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJT6hBqAAoJEIP+FMlX6CvZDi0H/jFJPRxBIglzATvMDaho19fw Ao1OHP99dZn3XkKf/qfw4v90KttCEp5+3uQo34hhXNTLkvbm5KCsZDjOdL812d3G JjvEBWnU7480Av0QkvsYVoH+yjks0PIu6xEI+kQqKAAG4vbVxTi5ORg7HMkeOKAY 5Uyj5xjWi5JRn+V8pYcUr9wZZlvhEAuDbVATeg9dH6+FyH/4V9viNWWHBePi3Ocn HWPt7U/Cv55wLIxfjmw27C5Te3b/xNjxy9hk+1XrGMafiO7FU1ntgHmqswqN+lBR beORG0dRNl0fU6QY8dakssYzjwA0jgV9HKoonbUGlp+fPxRl2pNuoe7Mvn/y1nU= =Iuvx -----END PGP SIGNATURE----- [ CONTENT OF TYPE application/octet-stream SKIPPED ] [ CONTENT OF TYPE application/octet-stream SKIPPED ] [ CONTENT OF TYPE application/octet-stream SKIPPED ] [ CONTENT OF TYPE application/octet-stream SKIPPED ] [ CONTENT OF TYPE application/octet-stream SKIPPED ] [ 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