Information

Files

Advisory

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

            Xen Security Advisory CVE-2015-5165 / XSA-140
                              version 3

    QEMU leak of uninitialized heap memory in rtl8139 device model

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

Normalize version tags.

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

The QEMU model of the RTL8139 network card did not sufficiently
validate inputs in the C+ mode offload emulation. This results in
uninitialised memory from the QEMU process's heap being leaked to the
domain as well as to the network.

IMPACT
======

A guest may be able to read sensitive host-level data relating to
itself which resides in the QEMU process.

Such information may include things such as information relating to
real devices backing emulated devices or passwords which the host
administrator does not intend to share with the guest admin.

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

All Xen systems running x86 HVM guests without stubdomains which have
been configured with an emulated RTL8139 driver model (which is the
default) are vulnerable.

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

Both the traditional ("qemu-xen-traditional") or upstream-based
("qemu-xen") qemu device models are potentially vulnerable.

Systems running only PV guests are NOT vulnerable.

ARM systems are NOT vulnerable.

QEMU-XEN-TRADITIONAL
====================

The patches supplied by the Qemu Project are of course against recent
versions of qemu.  They cannot be applied directly to
qemu-xen-traditional.  The Xen Project Security Team do not feel we
have the resources to backport and qualify these substantial and
intrusive patches.

Users using qemu-xen-traditional with stub domains are not vulnerable,
because the stub dm is a deprivileged qemu guest instance.

Users using qemu-xen-traditional for compatibility with old guests can
avoid the vulnerability by switching to using a stub device model.

The Xen Project Security Team encourages users and downstreams who are
using qemu-xen-traditional and able to backport the patches to share
those patches with us, so that we may distribute them with an updated
advisory.

We will encourage the community to have a conversation, when this
advisory is released, about the continuing security support status of
qemu-xen-traditional in non-stub-dm configurations.

MITIGATION
==========

Avoiding the use of emulated network devices altogether, by specifying
a PV only VIF in the domain configuration file will avoid this
issue.

Avoiding the use of the RTL8139 device in favour of other emulations
will also avoid this issue.

Enabling stubdomains will mitigate this issue, by reducing the
information leak to only information belonging to the service domain.

qemu-dm stubdomains are only available with the "qemu-xen-traditional"
device model version.

CREDITS
=======

This issue was discovered by Donghai Zhu of Alibaba.

RESOLUTION
==========

Applying the appropriate attached patches resolves this issue.

xsa140-qemuu-unstable-?.patch  qemu-xen master, 4.5.x, 4.4.x
xsa140-qemuu-4.3-?.patch       qemu-xen 4.3.x, 4.2.x

$ sha256sum xsa140*.patch
12d0dc1a31449288ed5e562a1e9415c437b7a2799e8afa0b251e3957a0d8ab23  xsa140-qemuu-unstable-1.patch
c91a60b7d7e18ea95b31eca0ba940d53c14730fae1e50802375c9e5ab7d0f109  xsa140-qemuu-unstable-2.patch
99062a9cbf4b96de8f0aa8555291cf6e296a9dbdf22ad4e9285912ba02de9261  xsa140-qemuu-unstable-3.patch
82d2214a0bd42b03b72b26170e4c80699d74bc691b6e223780a693ad2e9c267a  xsa140-qemuu-unstable-4.patch
b728ae69e4a1d838bb1b4c5e6135e84fe8f6fc7e97fdc99915e7fc908edb4fd2  xsa140-qemuu-unstable-5.patch
6fb23646e05ef9a4b010d2a2c0235b6ee58a293f39ed40b6b1611115c948a79a  xsa140-qemuu-unstable-6.patch
ebcadb69110ea4672795b52472222ed1ffe67a83e37c5b7d401530f43137c587  xsa140-qemuu-unstable-7.patch
f33046ad9f29878a6d6cc7fbd5f58959b26aa1f5fb5be3ff0c933a11d7ed51d8  xsa140-qemuu-4.3-1.patch
2d43b2de5152623d8beb4e304330c09bc6bd338343e4398d74ae256623d00007  xsa140-qemuu-4.3-2.patch
54a9d5b64e3562ba68a68178a292a125ca7c73edd24ec4fc3cb5908728ff75c9  xsa140-qemuu-4.3-3.patch
b803887acb91ae52c90ef478068bd588e06c84a4ef4b92a8bfb776b79ac8f318  xsa140-qemuu-4.3-4.patch
bb4130ae38ca515e76dcac0fcb895d2e8780bab75576096372292d1707d3134e  xsa140-qemuu-4.3-5.patch
e1acc11ef537c747c118da758cf160d738576ff9efce950eed3c71c889f843f4  xsa140-qemuu-4.3-6.patch
6fabe8336e8d847366d51670b356c70a994eaf286733043209ef9ac51d67384c  xsa140-qemuu-4.3-7.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 any of the mitigations described above is NOT
permitted (except on systems used and administered 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.

Also, 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+8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ8fgH/j3phBHA5Pe7ofmtt/ZNvUOlVyLZD59p9GHOn4Hn
liscQDPtHT1paJs3cFw+Pyr3G0utSlmPHQtis6Gfi9bs6QWcA3KLG53UjK51DoEa
7hoj2lyipoztxkPam/34JHOK2KB2tFLBjTMVh9Er38caxVAFV6HkD23FIPRWZw+9
vbCkU9R2SWs5YcyR8VOO9q58BvbIE89JkQGZmDTqjMQ5giAiGpIpwif0lfwOqBy5
+BFWDAKu5BG1LmrCU96Tq42HfBWizjN7aCVWPArGlryGCu1A0qSGXauF008cNWc4
bvv+HQmi1L3FHxE5ZPexKv4U4YAKJXMgV5NQemF0eN0ydzo=
=7FDP
-----END PGP SIGNATURE-----