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-----
Download attachment "xsa102-4.4-01.patch" of type "application/octet-stream" (1528 bytes)Download attachment "xsa102-4.4-02.patch" of type "application/octet-stream" (7859 bytes)Download attachment "xsa102-4.4-03.patch" of type "application/octet-stream" (1400 bytes)Download attachment "xsa102-unstable-01.patch" of type "application/octet-stream" (1529 bytes)Download attachment "xsa102-unstable-02.patch" of type "application/octet-stream" (8060 bytes)Download attachment "xsa102-unstable-03.patch" of type "application/octet-stream" (1377 bytes)