* Xen Security Advisory 186 (CVE-2016-7093) - x86: Mishandling of instruction pointer truncation during emulation
@ 2016-09-08 12:00 Xen.org security team
0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2016-09-08 12:00 UTC (permalink / raw)
To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team
[-- Attachment #1: Type: text/plain, Size: 4297 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2016-7093 / XSA-186
version 4
x86: Mishandling of instruction pointer truncation during emulation
UPDATES IN VERSION 4
====================
Public release.
ISSUE DESCRIPTION
=================
When emulating HVM instructions, Xen uses a small i-cache for fetches
from guest memory. The code that handles cache misses does not check
if the address from which it fetched lies within the cache before
blindly writing to it. As such it is possible for the guest to
overwrite hypervisor memory.
It is currently believed that the only way to trigger this bug is to
use the way that Xen currently incorrectly wraps CS:IP in 16 bit
modes. The included patch prevents such wrapping.
IMPACT
======
A malicious HVM guest administrator can escalate their privilege to that
of the host.
VULNERABLE SYSTEMS
==================
Xen versions 4.7.0 and later are vulnerable.
Xen releases 4.6.3 and 4.5.3 are vulnerable.
Xen releases 4.6.0 to 4.6.2 inclusive are NOT vulnerable.
Xen releases 4.5.2 and earlier are NOT vulnerable.
The vulnerability is only exposed to HVM guests on x86 hardware.
The vulnerability is not exposed to x86 PV guests, or ARM guests.
MITIGATION
==========
Running only PV guests will avoid this vulnerability.
CREDITS
=======
This issue was discovered by Brian Marcotte.
RESOLUTION
==========
Applying the first patch will resolve the issue.
Users wishing to independently verify the correctness of the fix may
find the second patch helpful. The second patch makes it easier to
use the "fep" (Force Emulation Prefix) feature to reproduce the
erroneous condition in a test environment. The "fep" feature requires
explicit enablement on the hypervisor command line, and is unsuitable
for production systems. Accordingly, applying the second patch does
not affect production systems and does not improve security.
Xen version First patch Second patch
xen-unstable: xsa186-0001-*.patch xsa186-0002-*.patch
Xen 4.7.x: xsa186-0001-*.patch xsa186-4.7-0002-*.patch
Xen 4.6.3: xsa186-0001-*.patch xsa186-4.6-0002-*.patch
Xen 4.5.3: xsa186-0001-*.patch xsa186-4.6-0002-*.patch
$ sha256sum xsa186*
f2082a36d968a47e477bb5082d0e0aaa58e6cb3dc20b26389f043a9b7b595fa6 xsa186-0001-x86-emulate-Correct-boundary-interactions-of-emulate.patch
412fa58edcbd1c7fdbfec7e28898cf98585593e6a24ccfb088dc0b84715286a5 xsa186-0002-hvm-fep-Allow-testing-of-instructions-crossing-the-1.patch
7482a823c3443e26dee1111c4904162845eaa9f826aa7bf8348007406d91bddd xsa186-4.6-0002-hvm-fep-Allow-testing-of-instructions-crossing-the.patch
5a826a32763d82ac83c924f8c89d12aae5f069a4cbc7d5193aa8413a02b6dc05 xsa186-4.7-0002-hvm-fep-Allow-testing-of-instructions-crossing-the.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
iQEcBAEBAgAGBQJX0VLsAAoJEIP+FMlX6CvZoUoIAMvgdMZRYdK5MaaRUAA1hDG3
UFSxZCH8zja6wZG6WPNj7VqvEkQ2350oqb05BGB8jTFCmqtNDDIyHK68WaMpwDMv
EEeetosujnlHTtVV7N8e0HO7F497PzZtzfniTyZc/h2Lna552ohMy/UcADtA7xxP
IK6qwvxpkx1aLzsDFpHIdrVcttDD/oZcVbBFwcCAqK33eGNC3S6BJvIibCAKfO8h
YKiAtvWUNsX/o4L9Zs4M50/pK3TzWsaDjfK3IX5LJPtsrcrKklrALVnDUOpTz1WA
07UIk0BcrzicEuTvuATWSQ3nVxUXAH95io23PCniHHntBtYJHjGA5rIqX+tiN6w=
=HT+K
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa186-0001-x86-emulate-Correct-boundary-interactions-of-emulate.patch --]
[-- Type: application/octet-stream, Size: 2346 bytes --]
From e938be013ba73ff08fa4f1d8670501aacefde7fb Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 22 Jul 2016 16:02:54 +0000
Subject: [PATCH 1/2] x86/emulate: Correct boundary interactions of emulated
instructions
This reverts most of c/s 0640ffb6 "x86emul: fix rIP handling".
Experimentally, in long mode processors will execute an instruction stream
which crosses the 64bit -1 -> 0 virtual boundary, whether the instruction
boundary is aligned on the virtual boundary, or is misaligned.
In compatibility mode, Intel processors will execute an instruction stream
which crosses the 32bit -1 -> 0 virtual boundary, while AMD processors raise a
segmentation fault. Xen's segmentation behaviour matches AMD.
For 16bit code, hardware does not ever truncated %ip. %eip is always used and
behaves normally as a 32bit register, including in 16bit protected mode
segments, as well as in Real and Unreal mode.
This is XSA-186
Reported-by: Brian Marcotte <marcotte@panix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
xen/arch/x86/x86_emulate/x86_emulate.c | 22 ++++------------------
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index d5a56cf..bf3529a 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1570,10 +1570,6 @@ x86_emulate(
#endif
}
- /* Truncate rIP to def_ad_bytes (2 or 4) if necessary. */
- if ( def_ad_bytes < sizeof(_regs.eip) )
- _regs.eip &= (1UL << (def_ad_bytes * 8)) - 1;
-
/* Prefix bytes. */
for ( ; ; )
{
@@ -3906,21 +3902,11 @@ x86_emulate(
/* Commit shadow register state. */
_regs.eflags &= ~EFLG_RF;
- switch ( __builtin_expect(def_ad_bytes, sizeof(_regs.eip)) )
- {
- uint16_t ip;
- case 2:
- ip = _regs.eip;
- _regs.eip = ctxt->regs->eip;
- *(uint16_t *)&_regs.eip = ip;
- break;
-#ifdef __x86_64__
- case 4:
- _regs.rip = _regs._eip;
- break;
-#endif
- }
+ /* Zero the upper 32 bits of %rip if not in long mode. */
+ if ( def_ad_bytes < sizeof(_regs.eip) )
+ _regs.eip = (uint32_t)_regs.eip;
+
*ctxt->regs = _regs;
done:
--
2.1.4
[-- Attachment #3: xsa186-0002-hvm-fep-Allow-testing-of-instructions-crossing-the-1.patch --]
[-- Type: application/octet-stream, Size: 2441 bytes --]
From 43eeed3a8da46e8fd3a96a3b09097ec92d835841 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 12 Aug 2016 14:35:28 +0100
Subject: [PATCH 2/2] hvm/fep: Allow testing of instructions crossing the -1 ->
0 virtual boundary
The Force Emulation Prefix is named to follow its PV counterpart for cpuid or
rdtsc, but isn't really an instruction prefix. It behaves as a break-out into
Xen, with the purpose of emulating the next instruction in the current state.
It is important to be able to test legal situations which occur in real
hardware, including instruction which cross certain boundaries, and
instructions starting at 0.
Reported-by: Brian Marcotte <marcotte@panix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
xen/arch/x86/hvm/hvm.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 893eff6..eab7cc9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3900,15 +3900,8 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
unsigned long addr;
char sig[5]; /* ud2; .ascii "xen" */
- /*
- * Note that in the call below we pass 1 more than the signature
- * size, to guard against the overall code sequence wrapping between
- * "prefix" and actual instruction. There's necessarily at least one
- * actual instruction byte required, so this won't cause failure on
- * legitimate uses.
- */
if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->eip,
- sizeof(sig) + 1, hvm_access_insn_fetch,
+ sizeof(sig), hvm_access_insn_fetch,
(hvm_long_mode_enabled(cur) &&
cs->attr.fields.l) ? 64 :
cs->attr.fields.db ? 32 : 16, &addr) &&
@@ -3918,6 +3911,11 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
{
regs->eip += sizeof(sig);
regs->eflags &= ~X86_EFLAGS_RF;
+
+ /* Zero the upper 32 bits of %rip if not in long mode. */
+ if ( !(hvm_long_mode_enabled(cur) && cs->attr.fields.l) )
+ regs->eip = regs->_eip;
+
add_taint(TAINT_HVM_FEP);
}
}
--
2.1.4
[-- Attachment #4: xsa186-4.6-0002-hvm-fep-Allow-testing-of-instructions-crossing-the.patch --]
[-- Type: application/octet-stream, Size: 1516 bytes --]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: hvm/fep: Allow testing of instructions crossing the -1 -> 0 virtual boundary
The Force Emulation Prefix is named to follow its PV counterpart for cpuid or
rdtsc, but isn't really an instruction prefix. It behaves as a break-out into
Xen, with the purpose of emulating the next instruction in the current state.
It is important to be able to test legal situations which occur in real
hardware, including instruction which cross certain boundaries, and
instructions starting at 0.
Reported-by: Brian Marcotte <marcotte@panix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2139,6 +2139,10 @@ static void svm_vmexit_ud_intercept(stru
{
regs->eip += sizeof(sig);
regs->eflags &= ~X86_EFLAGS_RF;
+
+ /* Zero the upper 32 bits of %rip if not in long mode. */
+ if ( svm_guest_x86_mode(current) != 8 )
+ regs->eip = regs->_eip;
}
}
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2757,6 +2757,10 @@ static void vmx_vmexit_ud_intercept(stru
{
regs->eip += sizeof(sig);
regs->eflags &= ~X86_EFLAGS_RF;
+
+ /* Zero the upper 32 bits of %rip if not in long mode. */
+ if ( vmx_guest_x86_mode(current) != 8 )
+ regs->eip = regs->_eip;
}
}
[-- Attachment #5: xsa186-4.7-0002-hvm-fep-Allow-testing-of-instructions-crossing-the.patch --]
[-- Type: application/octet-stream, Size: 1113 bytes --]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: hvm/fep: Allow testing of instructions crossing the -1 -> 0 virtual boundary
The Force Emulation Prefix is named to follow its PV counterpart for cpuid or
rdtsc, but isn't really an instruction prefix. It behaves as a break-out into
Xen, with the purpose of emulating the next instruction in the current state.
It is important to be able to test legal situations which occur in real
hardware, including instruction which cross certain boundaries, and
instructions starting at 0.
Reported-by: Brian Marcotte <marcotte@panix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3905,6 +3905,10 @@ void hvm_ud_intercept(struct cpu_user_re
{
regs->eip += sizeof(sig);
regs->eflags &= ~X86_EFLAGS_RF;
+
+ /* Zero the upper 32 bits of %rip if not in long mode. */
+ if ( !(hvm_long_mode_enabled(cur) && cs.attr.fields.l) )
+ regs->eip = regs->_eip;
}
}
[-- Attachment #6: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2016-09-08 12:00 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-08 12:00 Xen Security Advisory 186 (CVE-2016-7093) - x86: Mishandling of instruction pointer truncation during emulation Xen.org security team
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).