[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] Xen Security Advisory 183 (CVE-2016-6259) - x86: Missing SMAP whitelisting in 32-bit
From: Xen.org security team <security () xen ! org>
Date: 2016-07-26 12:05:17
Message-ID: E1bS16r-00051A-AE () xenbits ! xenproject ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2016-6259 / XSA-183
version 5
x86: Missing SMAP whitelisting in 32-bit exception / event delivery
UPDATES IN VERSION 5
====================
Public release.
ISSUE DESCRIPTION
=================
Supervisor Mode Access Prevention is a hardware feature designed to make
an Operating System more robust, by raising a pagefault rather than
accidentally following a pointer into userspace. However, legitimate
accesses into userspace require whitelisting, and the exception delivery
mechanism for 32bit PV guests wasn't whitelisted.
IMPACT
======
A malicious 32-bit PV guest kernel can trigger a safety check, crashing
the hypervisor and causing a denial of service to other VMs on the host.
VULNERABLE SYSTEMS
==================
Xen version 4.5 and newer are vulnerable. Versions 4.4 and older are
not, due to not having software support for SMAP.
The vulnerability is only exposed on x86 hardware supporting the SMAP
feature (Intel Broadwell and later CPUs). The vulnerability is not
exposed on ARM hardware, or x86 hardware which do not support SMAP.
The vulnerability is only exposed to x86 32bit PV guests. The
vulnerability is not exposed to 64bit PV guests or HVM guests.
MITIGATION
==========
Running only HVM guests or 64-bit PV guests, avoids the vulnerability.
Disabling SMAP in the hypervisor by booting Xen with "smap=0" on the
command line will avoid this vulnerability. (Depending on the
circumstances this workaround may pose a small risk of increasing the
impact of other, possibly unknown, vulnerabilities.)
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa183.patch xen-unstable, 4.7.x
xsa183-4.6.patch Xen 4.6.x, 4.5.x
$ sha256sum xsa183*
ea0ea4b294332814330f222e6d78eea3b19c394eac8ae22feb4a5bd21e90331f xsa183-unstable.patch
0fee41f21a3eb4af1487590098047f4625688bcef7419572a8f418f9fb728468 xsa183-4.6.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the patches 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: Deployment of the "smap=0" mitigation is NOT permitted (except
where all the affected systems and VMs are administered and used only
by organisations which are members of the Xen Project Security Issues
Predisclosure List). Specifically, deployment on public cloud systems
is NOT permitted. This is because this produces a guest-visible
change which could lead to rediscovery of the vulnerability.
And: 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
iQEcBAEBAgAGBQJXl0M9AAoJEIP+FMlX6CvZYB4IAIkCjnrkDBqYcPJrnAAjNDGL
v/qJiE6NAKlvqyi/pRkDodAk+5CLvvjDHmTBtqvT+7SU3ixt4C80MLiVMCuJVsUw
kMcp95KsJne1TSoivAqSXED+J3gkIWXG8PYvpUOwwOqr0aJViuN9Uv52g0+MVUsW
OnkHzYzyyMkIRi0bIzXmhvGeHTUxVhcz8RjMWsjD9FPb+i6lu/kfNUvpiecVa0mx
0J7ByS5l4iEefCH+beT35NFg1BfQINU3cMmDM/i8pklRuJI+HKCYFzPGJyl2+Ccr
0Zd7Lgub2jGsJjgXjBBPCHw/CCdlmX7RiiAvnIQU5adBtCIk6p0T0ugcGXwTIAw=
=ydwH
-----END PGP SIGNATURE-----
["xsa183-unstable.patch" (application/octet-stream)]
From 2fd4f34058fb5f87fbd80978dbd2cb458aff565d Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 15 Jun 2016 18:32:14 +0100
Subject: [PATCH] x86/entry: Avoid SMAP violation in
compat_create_bounce_frame()
A 32bit guest kernel might be running on user mappings.
compat_create_bounce_frame() must whitelist its guest accesses to avoid
risking a SMAP violation.
For both variants of create_bounce_frame(), re-blacklist user accesses if
execution exits via an exception table redirection.
This is XSA-183 / CVE-2016-6259
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
v2:
* Include CLAC on the exit paths from compat_create_bounce_frame which occur
from faults attempting to load %fs
* Reposition ASM_STAC to avoid breaking the macro-op fusion of test/jz
---
xen/arch/x86/x86_64/compat/entry.S | 3 +++
xen/arch/x86/x86_64/entry.S | 2 ++
2 files changed, 5 insertions(+)
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index 7f02afd..e80c53c 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -318,6 +318,7 @@ ENTRY(compat_int80_direct_trap)
compat_create_bounce_frame:
ASSERT_INTERRUPTS_ENABLED
mov %fs,%edi
+ ASM_STAC
testb $2,UREGS_cs+8(%rsp)
jz 1f
/* Push new frame at registered guest-OS stack base. */
@@ -364,6 +365,7 @@ compat_create_bounce_frame:
movl TRAPBOUNCE_error_code(%rdx),%eax
.Lft8: movl %eax,%fs:(%rsi) # ERROR CODE
1:
+ ASM_CLAC
/* Rewrite our stack frame and return to guest-OS mode. */
/* IA32 Ref. Vol. 3: TF, VM, RF and NT flags are cleared on trap. */
andl $~(X86_EFLAGS_VM|X86_EFLAGS_RF|\
@@ -403,6 +405,7 @@ compat_crash_page_fault_4:
addl $4,%esi
compat_crash_page_fault:
.Lft14: mov %edi,%fs
+ ASM_CLAC
movl %esi,%edi
call show_page_walk
jmp dom_crash_sync_extable
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index ad8c64c..f7178cd 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -420,9 +420,11 @@ domain_crash_page_fault_16:
domain_crash_page_fault_8:
addq $8,%rsi
domain_crash_page_fault:
+ ASM_CLAC
movq %rsi,%rdi
call show_page_walk
ENTRY(dom_crash_sync_extable)
+ ASM_CLAC
# Get out of the guest-save area of the stack.
GET_STACK_END(ax)
leaq STACK_CPUINFO_FIELD(guest_cpu_user_regs)(%rax),%rsp
--
2.1.4
["xsa183-4.6.patch" (application/octet-stream)]
From 777ebe30e81ab284f9b78392875fe884a593df35 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 15 Jun 2016 18:32:14 +0100
Subject: [PATCH] x86/entry: Avoid SMAP violation in
compat_create_bounce_frame()
A 32bit guest kernel might be running on user mappings.
compat_create_bounce_frame() must whitelist its guest accesses to avoid
risking a SMAP violation.
For both variants of create_bounce_frame(), re-blacklist user accesses if
execution exits via an exception table redirection.
This is XSA-183 / CVE-2016-6259
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
v2:
* Include CLAC on the exit paths from compat_create_bounce_frame which occur
from faults attempting to load %fs
* Reposition ASM_STAC to avoid breaking the macro-op fusion of test/jz
---
xen/arch/x86/x86_64/compat/entry.S | 3 +++
xen/arch/x86/x86_64/entry.S | 2 ++
2 files changed, 5 insertions(+)
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index 0e3db7c..1eaf4bb 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -350,6 +350,7 @@ ENTRY(compat_int80_direct_trap)
compat_create_bounce_frame:
ASSERT_INTERRUPTS_ENABLED
mov %fs,%edi
+ ASM_STAC
testb $2,UREGS_cs+8(%rsp)
jz 1f
/* Push new frame at registered guest-OS stack base. */
@@ -403,6 +404,7 @@ UNLIKELY_START(nz, compat_bounce_failsafe)
movl %ds,%eax
.Lft12: movl %eax,%fs:0*4(%rsi) # DS
UNLIKELY_END(compat_bounce_failsafe)
+ ASM_CLAC
/* Rewrite our stack frame and return to guest-OS mode. */
/* IA32 Ref. Vol. 3: TF, VM, RF and NT flags are cleared on trap. */
andl $~(X86_EFLAGS_VM|X86_EFLAGS_RF|\
@@ -448,6 +450,7 @@ compat_crash_page_fault_4:
addl $4,%esi
compat_crash_page_fault:
.Lft14: mov %edi,%fs
+ ASM_CLAC
movl %esi,%edi
call show_page_walk
jmp dom_crash_sync_extable
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 6e27508..0c2e63a 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -462,9 +462,11 @@ domain_crash_page_fault_16:
domain_crash_page_fault_8:
addq $8,%rsi
domain_crash_page_fault:
+ ASM_CLAC
movq %rsi,%rdi
call show_page_walk
ENTRY(dom_crash_sync_extable)
+ ASM_CLAC
# Get out of the guest-save area of the stack.
GET_STACK_BASE(%rax)
leaq STACK_CPUINFO_FIELD(guest_cpu_user_regs)(%rax),%rsp
--
2.1.4
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic