Xen Security Advisory 200 (CVE-2016-9932) - x86 CMPXCHG8B emulation fails to ignore operand size override

Xen Security Advisory 200 (CVE-2016-9932) - x86 CMPXCHG8B emulation fails to ignore operand size override

[Xen.org security team]

[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2016-9932 / XSA-200
                              version 3

     x86 CMPXCHG8B emulation fails to ignore operand size override

UPDATES IN VERSION 3
====================

CVE assigned.

Public release.

ISSUE DESCRIPTION
=================

The x86 instruction CMPXCHG8B is supposed to ignore legacy operand
size overrides; it only honors the REX.W override (making it
CMPXCHG16B).  So, the operand size is always 8 or 16.

When support for CMPXCHG16B emulation was added to the instruction
emulator, this restriction on the set of possible operand sizes was
relied on in some parts of the emulation; but a wrong, fully general,
operand size value was used for other parts of the emulation.

As a result, if a guest uses a supposedly-ignored operand size prefix,
a small amount of hypervisor stack data is leaked to the guests: a 96
bit leak to guests running in 64-bit mode; or, a 32 bit leak to other
guests.

IMPACT
======

A malicious unprivileged guest may be able to obtain sensitive
information from the host.

VULNERABLE SYSTEMS
==================

Xen versions 3.3 through 4.7 are affected.  Xen master and Xen 4.8 as
well as Xen versions 3.2 and earlier are not affected.

Only x86 systems are affected.  ARM systems are not affected.

On Xen 4.6 and earlier the vulnerability is exposed to all HVM guest
user processes, including unprivileged processes.

On Xen 4.7, the vulnerability is exposed only to HVM guest user
processes granted a degree of privilege (such as direct hardware
access) by the guest administrator; or, to all user processes when the
VM has been explicitly configured with a non-default cpu vendor string
(in xm/xl, this would be done with a `cpuid=' domain config option).

MITIGATION
==========

There is no known mitigation.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa200-4.7.patch       Xen 4.7.x
xsa200-4.6.patch       Xen 4.6.x, Xen 4.5.x, Xen 4.4.x

$ sha256sum xsa200*
820e95e87b838de5eb4158a55c81cf205428f0ed17009dc8d45b2392cf9a0885  xsa200-4.6.patch
d7113b94f6ef1c2849aedfe33eace85b0713fa83639c8a533fb289aa73e818e8  xsa200-4.7.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

iQEcBAEBAgAGBQJYT/KgAAoJEIP+FMlX6CvZR6QH/0eEM2+9ixdfFAiyhFzn0TTq
mLgbKs4L0ALfPD2JVhkiLlB/thJ7RKXfPAsYVBQhNY+xb58OLykH4Clh0NuOY45W
wkWxHeunHAfsNo3FIaISr/uG/5fAnarPsfF+bNYpyWCuWLz4Ml+uuflnfL60PmoP
OGSPLEPKZ56r9lyaIALFVfkXgHkaquM/WXi+FdG23aArbT43cVHeGou8dUNbH/Jd
FpKdO3AhMT9i+ioPeicSIimxLOEBZnrCaB/7qOAzu7q3nlQ8X/1Q8a8TjjOtYtQA
/kOkvpexkQuRA98AI6018ajqU/D5VdFW+I2X0kmbTAxj1SyT12X25f9Wsc0PbdE=
=ERcI
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa200-4.6.patch --]
[-- Type: application/octet-stream, Size: 1935 bytes --]

From: Jan Beulich <jbeulich@suse.com>
Subject: x86emul: CMPXCHG8B ignores operand size prefix

Otherwise besides mis-handling the instruction, the comparison failure
case would result in uninitialized stack data being handed back to the
guest in rDX:rAX (32 bits leaked for 32-bit guests, 96 bits for 64-bit
ones).

This is XSA-200.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -429,6 +429,24 @@ int main(int argc, char **argv)
         goto fail;
     printf("okay\n");
 
+    printf("%-40s", "Testing cmpxchg8b (%edi) [opsize]...");
+    instr[0] = 0x66; instr[1] = 0x0f; instr[2] = 0xc7; instr[3] = 0x0f;
+    res[0]      = 0x12345678;
+    res[1]      = 0x87654321;
+    regs.eflags = 0x200;
+    regs.eip    = (unsigned long)&instr[0];
+    regs.edi    = (unsigned long)res;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (res[0] != 0x12345678) ||
+         (res[1] != 0x87654321) ||
+         (regs.eax != 0x12345678) ||
+         (regs.edx != 0x87654321) ||
+         ((regs.eflags&0x240) != 0x200) ||
+         (regs.eip != (unsigned long)&instr[4]) )
+        goto fail;
+    printf("okay\n");
+
     printf("%-40s", "Testing movsxbd (%%eax),%%ecx...");
     instr[0] = 0x0f; instr[1] = 0xbe; instr[2] = 0x08;
     regs.eflags = 0x200;
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4739,8 +4739,12 @@ x86_emulate(
         generate_exception_if((modrm_reg & 7) != 1, EXC_UD, -1);
         generate_exception_if(ea.type != OP_MEM, EXC_UD, -1);
         if ( op_bytes == 8 )
+        {
             vcpu_must_have_cx16();
-        op_bytes *= 2;
+            op_bytes = 16;
+        }
+        else
+            op_bytes = 8;
 
         /* Get actual old value. */
         if ( (rc = ops->read(ea.mem.seg, ea.mem.off, old, op_bytes,

[-- Attachment #3: xsa200-4.7.patch --]
[-- Type: application/octet-stream, Size: 1943 bytes --]

From: Jan Beulich <jbeulich@suse.com>
Subject: x86emul: CMPXCHG8B ignores operand size prefix

Otherwise besides mis-handling the instruction, the comparison failure
case would result in uninitialized stack data being handed back to the
guest in rDX:rAX (32 bits leaked for 32-bit guests, 96 bits for 64-bit
ones).

This is XSA-200.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -435,6 +435,24 @@ int main(int argc, char **argv)
         goto fail;
     printf("okay\n");
 
+    printf("%-40s", "Testing cmpxchg8b (%edi) [opsize]...");
+    instr[0] = 0x66; instr[1] = 0x0f; instr[2] = 0xc7; instr[3] = 0x0f;
+    res[0]      = 0x12345678;
+    res[1]      = 0x87654321;
+    regs.eflags = 0x200;
+    regs.eip    = (unsigned long)&instr[0];
+    regs.edi    = (unsigned long)res;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (res[0] != 0x12345678) ||
+         (res[1] != 0x87654321) ||
+         (regs.eax != 0x12345678) ||
+         (regs.edx != 0x87654321) ||
+         ((regs.eflags&0x240) != 0x200) ||
+         (regs.eip != (unsigned long)&instr[4]) )
+        goto fail;
+    printf("okay\n");
+
     printf("%-40s", "Testing movsxbd (%%eax),%%ecx...");
     instr[0] = 0x0f; instr[1] = 0xbe; instr[2] = 0x08;
     regs.eflags = 0x200;
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4775,8 +4775,12 @@ x86_emulate(
         generate_exception_if((modrm_reg & 7) != 1, EXC_UD, -1);
         generate_exception_if(ea.type != OP_MEM, EXC_UD, -1);
         if ( op_bytes == 8 )
+        {
             host_and_vcpu_must_have(cx16);
-        op_bytes *= 2;
+            op_bytes = 16;
+        }
+        else
+            op_bytes = 8;
 
         /* Get actual old value. */
         if ( (rc = ops->read(ea.mem.seg, ea.mem.off, old, op_bytes,

[-- Attachment #4: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel