Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 556304 - <app-emulation/xen-tools-4.5.1-r3: Use after free in QEMU/Xen block unplug protocol and QEMU leak of uninitialized heap memory in rtl8139 device model (XSA-{139,140})
Summary: <app-emulation/xen-tools-4.5.1-r3: Use after free in QEMU/Xen block unplug pr...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: A3 [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-30 09:16 UTC by Kristian Fiskerstrand (RETIRED)
Modified: 2016-04-05 07:00 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-07-30 09:16:25 UTC
Xen Security Advisory XSA-139

           Use after free in QEMU/Xen block unplug protocol

              *** EMBARGOED UNTIL 2015-08-03 12:00 UTC ***

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

When unplugging an emulated block device the device was not fully
unplugged, meaning a second unplug attempt would attempt to unplug the
device a second time using a previously freed pointer.

IMPACT
======

An HVM guest which has access to an emulated IDE disk device may be
able to exploit this vulnerability in order to take over the qemu
process elevating its privilege to that of the qemu process.

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

All Xen systems running x86 HVM guests using the upstream based
"qemu-xen" are vulnerable.

Systems using the "qemu-xen-traditional" version of the qemu device
model, either in a stubdomain or as a domain 0 process, are not vulnerable.

Systems running only PV guests are NOT vulnerable.

ARM systems are not vulnerable.

MITIGATION
==========

There is no known mitigation for this issue.

RESOLUTION
==========

The attached patches have been proposed as fixes for the issue.  They
have not been fully reviewed and tested.  We are sending them out now
because there are less than 2 weeks left until the embargo is lifted.
Please send review comments and test reports of the patches to
xen-security-issues-discuss@lists.xenproject.org.

xsa139-qemuu-unstable.patch        qemu-upstream, xen-unstable
xsa139-qemuu-4.5.patch             qemu-upstream, Xen 4.5.x, Xen
                                   4.4.x, Xen 4.3.x, Xen 4.2.x

$ sha256sum xsa139*.patch
dead84667dd4868d0688dc4e62a54a14883e6f0352cf3318b277aa37e27c9261  xsa139-qemuu-unstable.patch
3aa775255053d1d14a3e383998240eb3520aea7de137cdb7624b169db8b06d85  xsa139-qemuu-4.5.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
##
  Xen Security Advisory XSA-140

    QEMU leak of uninitialized heap memory in rtl8139 device model

              *** EMBARGOED UNTIL 2015-08-03 12:00 UTC ***

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.

RESOLUTION
==========

The attached patches have been proposed as fixes for the issue.  They
have not been fully reviewed and tested.  We are sending them out now
because there are less than 2 weeks left until the embargo is lifted.
Please send review comments and test reports of the patches to
xen-security-issues-discuss@lists.xenproject.org.

xsa140-qemuu-unstable-?.patch        qemu-upstream, xen-unstable, Xen 4.5.x,
                                     Xen 4.4.x
xsa140-qemuu-4.3-?.patch             qemu-upstream, Xen 4.3.x, Xen 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
Comment 1 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-07-30 09:22:23 UTC
patches have been sent to dlan by mail. 

This affects qemu as well, cardoe, please confirm that you have read and understood the deployment during embargo and security policies.
Comment 2 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-07-30 10:01:12 UTC
(In reply to Kristian Fiskerstrand from comment #1)
> patches have been sent to dlan by mail. 
> 
> This affects qemu as well, cardoe, please confirm that you have read and
> understood the deployment during embargo and security policies.

... if you want me to send you the patches by email, that is
Comment 3 Doug Goldstein (RETIRED) gentoo-dev 2015-07-30 13:23:14 UTC
(In reply to Kristian Fiskerstrand from comment #1)
> patches have been sent to dlan by mail. 
> 
> This affects qemu as well, cardoe, please confirm that you have read and
> understood the deployment during embargo and security policies.

ACK. I agree to them and understand them.
Comment 4 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-08-03 12:53:47 UTC
Issue is now public
Comment 5 SpanKY gentoo-dev 2015-08-04 02:07:44 UTC
qemu-2.3.0-r5 is in the tree

note: we should also stabilize qemu-guest-agent-2.3.0 too to keep in sync
Comment 6 Yixun Lan archtester gentoo-dev 2015-08-05 10:03:18 UTC
+*xen-tools-4.5.1-r3 (05 Aug 2015)
+*xen-tools-4.2.5-r10 (05 Aug 2015)
+
+  05 Aug 2015; Yixun Lan <dlan@gentoo.org> +xen-tools-4.2.5-r10.ebuild,
+  +xen-tools-4.5.1-r3.ebuild:
+  security bump, bug 556304, fix XSA139,140


Arches, please test and mark stable:
=app-emulation/xen-tools-4.2.5-r10
Target keywords Both : "amd64 x86"

=app-emulation/xen-tools-4.5.1-r3
Target keywords Only: "amd64"
Comment 7 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2015-08-05 11:48:46 UTC
Marked stable.

Added to existing glsa draft
Comment 8 Yixun Lan archtester gentoo-dev 2015-08-06 01:28:17 UTC
+  06 Aug 2015; Yixun Lan <dlan@gentoo.org> -xen-tools-4.2.5-r9.ebuild,
+  -xen-tools-4.5.1-r2.ebuild:
+  cleanup old vulnerable versions, bug 556304
Comment 9 Aaron Bauman (RETIRED) gentoo-dev 2016-03-12 11:07:35 UTC
Added to existing GLSA.
Comment 10 GLSAMaker/CVETool Bot gentoo-dev 2016-04-05 07:00:59 UTC
This issue was resolved and addressed in
 GLSA 201604-03 at https://security.gentoo.org/glsa/201604-03
by GLSA coordinator Yury German (BlueKnight).