Xen Security Advisory 199 (CVE-2016-9637) - qemu ioport array overflow

Xen Security Advisory 199 (CVE-2016-9637) - qemu ioport array overflow

[Xen.org security team]

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

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

            Xen Security Advisory CVE-2016-9637 / XSA-199
                              version 3

                      qemu ioport array overflow

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

Clarify the IMPACT description, by escalating privilege to that of the
qemu process, not necesserily the host.

Public release.

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

The code in qemu which implements ioport read/write looks up the
specified ioport address in a dispatch table.  The argument to the
dispatch function is a uint32_t, and is used without a range check,
even though the table has entries for only 2^16 ioports.

When qemu is used as a standalone emulator, ioport accesses are
generated only from cpu instructions emulated by qemu, and are
therefore necessarily 16-bit, so there is no vulnerability.

When qemu is used as a device model within Xen, io requests are
generated by the hypervisor and read by qemu from a shared ring.  The
entries in this ring use a common structure, including a 64-bit
address field, for various accesses, including ioport addresses.

Xen will write only 16-bit address ioport accesses.  However,
depending on the Xen and qemu version, the ring may be writeable by
the guest.  If so, the guest can generate out-of-range ioport
accesses, resulting in wild pointer accesses within qemu.


IMPACT
======

A malicious guest administrator can escalate their privilege to that
of the qemu process.


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

PV guests cannot exploit the vulnerability.

ARM systems are not vulnerable.

HVM domains run with QEMU stub domains cannot exploit the
vulnerability.  (A QEMU stub domain is used if xl's domain
configuration file contains "device_model_stubdomain_override=1".)

Guests using the modern "qemu-xen" device model, with a qemu version
of at least 1.6.0 (for example, as provided by the Xen Project in its
Xen 4.4.0 and later releases), cannot exploit the vulnerability.

x86 HVM guests, not configured with qemu stub domains, using a version
of qemu older than qemu upstream 1.6.0, can exploit the vulnerability.

x86 HVM guests using the traditional "qemu-xen-traditional", not
configured with qemu stub domains, can therefore exploit the
vulnerability.

In tabular form:

  Guest      Xen       QEMU    QEMU "traditional"            Status
  type       version   stub      and/or qemu version

  ARM        any       n/a     n/a         any               OK
  x86 PV     any       n/a     n/a         any               OK

  x86 HVM    any       yes     qemu-xen-traditional          OK

  x86 HVM    any       no      qemu-xen*   >= 1.6.0          OK
  x86 HVM    >= 4.4    no      qemu-xen*   Xen supplied      OK

  x86 HVM    any       no      qemu-xen*   < 1.6.0           Vulnerable
  x86 HVM    <= 4.3    no      qemu-xen*   Xen supplied      Vulnerable

  x86 HVM    any       no      qemu-xen-traditional          Vulnerable

[*] qemu-xen is the default when qemu stub domains are not in
    use, since Xen 4.3.


MITIGATION
==========

Enabling stubdomains will mitigate this issue, by reducing the
escalation to only those privileges accorded to the service domain.
In a usual configuration, a service domain has only the privilege of
the guest, so this eliminates the vulnerability.

Running HVM guests with the default upstream device model, in Xen 4.4
and later, will also avoid this vulnerability.


CREDITS
=======

This issue was discovered by yanghongke@huawei.com of the Huawei
Security Test Team.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa199-trad.patch      qemu-xen-traditional, all versions

$ sha256sum xsa199*
35c6a7d0d51c2347b46a9acf22e034ca328ca62b0ce4ad868a94c190b2e14d36  xsa199-trad.patch
$


DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patch described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

However deployment of the mitigations described above 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 in all cases the configuration change may be visible
to the guest which could lead to the rediscovery of the vulnerability.

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

iQEcBAEBAgAGBQJYRqr8AAoJEIP+FMlX6CvZ3tQIAKrYJRz+GjkoilWBFoUDNqrA
ruzFuDBa4RSxlQlGo4o1TiuDSCq7Fl46wLqdGmQh8NBtCSjcSTDY3vDwJH6ns8co
L7tM3DQt4EuP82jCxiNtLmiuzyTPkFUbYtIhciPyd6D4M6DffveD2OEpOYowK4Oo
9BRxuVb4lq6Xeke2X2S0sU1groFocfvf7Q6lWkpApWHVSx6wWCW+dewJ6x26lzn6
FmtQiAjWoF/zDox/nOL6uq2FEqa4wAZQGHkdyWR+yLnfEwhedUuLEiMWiUSSCPN3
erSXtqWnEVfiJevKZXhvV0YHm6WGDCj29nDvatVBDVuwmPF/BOCHBTSzb2lMfE4=
=FtuL
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa199-trad.patch --]
[-- Type: application/octet-stream, Size: 2901 bytes --]

From b73bd1edc05d1bad5c018228146930d79315a5da Mon Sep 17 00:00:00 2001
From: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 14 Nov 2016 17:19:46 +0000
Subject: [PATCH] qemu: ioport_read, ioport_write: be defensive about 32-bit
 addresses

On x86, ioport addresses are 16-bit.  That these functions take 32-bit
arguments is a mistake.  Changing the argument type to 16-bit will
discard the top bits of any erroneous values from elsewhere in qemu.

Also, check just before use that the value is in range.  (This turns
an ill-advised change to MAX_IOPORTS into a possible guest crash
rather than a privilege escalation vulnerability.)

And, in the Xen ioreq processor, clamp incoming ioport addresses to
16-bit values.  Xen will never write >16-bit values but the guest may
have access to the ioreq ring.  We want to defend the rest of the qemu
code from wrong values.

This is XSA-199.

Reported-by: yanghongke <yanghongke@huawei.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 i386-dm/helper2.c | 2 ++
 vl.c              | 9 +++++++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index 2706f2e..5d276bb 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -375,6 +375,8 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
 {
     uint32_t i;
 
+    req->addr &= 0x0ffffU;
+
     if (req->dir == IOREQ_READ) {
         if (!req->data_is_ptr) {
             req->data = do_inp(env, req->addr, req->size);
diff --git a/vl.c b/vl.c
index f9c4d7e..c3c5d63 100644
--- a/vl.c
+++ b/vl.c
@@ -52,6 +52,7 @@
 
 #include <xen/hvm/hvm_info_table.h>
 
+#include <assert.h>
 #include <unistd.h>
 #include <fcntl.h>
 #include <signal.h>
@@ -290,26 +291,30 @@ PicState2 *isa_pic;
 static IOPortReadFunc default_ioport_readb, default_ioport_readw, default_ioport_readl;
 static IOPortWriteFunc default_ioport_writeb, default_ioport_writew, default_ioport_writel;
 
-static uint32_t ioport_read(int index, uint32_t address)
+static uint32_t ioport_read(int index, uint16_t address)
 {
     static IOPortReadFunc *default_func[3] = {
         default_ioport_readb,
         default_ioport_readw,
         default_ioport_readl
     };
+    if (address >= MAX_IOPORTS)
+        abort();
     IOPortReadFunc *func = ioport_read_table[index][address];
     if (!func)
         func = default_func[index];
     return func(ioport_opaque[address], address);
 }
 
-static void ioport_write(int index, uint32_t address, uint32_t data)
+static void ioport_write(int index, uint16_t address, uint32_t data)
 {
     static IOPortWriteFunc *default_func[3] = {
         default_ioport_writeb,
         default_ioport_writew,
         default_ioport_writel
     };
+    if (address >= MAX_IOPORTS)
+        abort();
     IOPortWriteFunc *func = ioport_write_table[index][address];
     if (!func)
         func = default_func[index];
-- 
2.1.4


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

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