Information

Files

Advisory

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2015-8554 / XSA-164
                              version 4

               qemu-dm buffer overrun in MSI-X handling

UPDATES IN VERSION 4
====================

Normalize version tags.

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

"qemu-xen-traditional" (aka qemu-dm) tracks state for each MSI-X table
entry of a passed through device.  This is used/updated on
(intercepted) accesses to the page(s) containing the MSI-X table.

There may be space on the final page not covered by any MSI-X table
entry, but memory for state tracking is allocated only for existing
table entries.  Therefore bounds checks are required to avoid
accessing/corrupting unrelated heap memory.  Such a check is present
for the read path, but was missing for the write path.

IMPACT
======

A malicious administrator of a guest which has access to a passed
through PCI device which is MSI-X capable can exploit this
vulnerability to take over the qemu process, elevating its privilege
to that of the qemu process.

In a system not using a device model stub domain (or other techniques
for deprivileging qemu), the malicious guest administrator can thus
elevate their privilege to that of the host.

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

Xen systems running x86 HVM guests with "qemu-xen-traditional", but
without stubdomains, which have been passed through an MSI-X capable
physical PCI device are vulnerable.

The default configuration is NOT vulnerable from Xen 4.3 onwards
(because it uses a newer upstream qemu version).

Systems running only PV guests are NOT vulnerable.

Only systems using PCI passthrough are vulnerable.

Systems using "qemu-xen-traditional" stubdomain device models (for
example, by specifying "device_model_stubdomain_override=1" in xl's
domain configuration files) are NOT vulnerable.

Only the traditional "qemu-xen-traditional" device model is vulnerable.
Upstream qemu device models ("qemu-xen") are NOT vulnerable.

ARM systems are NOT vulnerable.

MITIGATION
==========

Not passing through MSI-X capable devices to HVM guests will avoid this
vulnerability.

Running HVM guests with the default upstream device model will also
avoid this vulnerability.

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.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa164.patch  qemu-xen-traditional master, 4.6.x, 4.5.x, 4.4.x, 4.3.x

$ sha256sum xsa164*
40f7327aa414c77a0e18a305a144e4a720ba8fe1b618d2f3ad9d5f605667c340  xsa164.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-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmV8b/IMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZIuIH/RjFgQoKRU0E9c7ay1qxqnuJ5lu3IcKAt1Cf1tKq
WCtMrORiMXA00y2w5BdryeKF0iAT4+uMhtwNZE6putzVJhsntyocPVRf9jNA4diU
BATkEJRv7GFTbaaew/3uY2bvUrxiSHd0Bmp+W81MrU9Myv/u8ikO80a5GsrxxCQM
yi+PGP91/8a4ahp2tiJ+0QLK+0VH8BYOEXzZPAwIpsr8ypkDA7+8WC9X6NE40jEH
wGht/IfeyKd7R/8QHMrMdOxUKwPiDoGll+9gJnzyUf64w+94w+YkbM0eoonGlgA5
NL0yU5zngP/slv4ANLCUWZL7ac4Fzc3FVWmrjiEzdg4s3MM=
=4cod
-----END PGP SIGNATURE-----