Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 30 Nov 2015 10:54:10 +0000
From: Xen.org security team <security@....org>
To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org,
 xen-users@...ts.xen.org, oss-security@...ts.openwall.com
CC: Xen.org security team <security@....org>
Subject: Xen Security Advisory 162 (CVE-2015-7504) - heap buffer overflow
 vulnerability in pcnet emulator

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

            Xen Security Advisory CVE-2015-7504 / XSA-162
                              version 2

         heap buffer overflow vulnerability in pcnet emulator

UPDATES IN VERSION 2
====================

Public release.

Correct cut and paste reference to bootloaders in "DEPLOYMENT DURING
EMBARGO" section, which should have instead referred to the
configuration changes.

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

The QEMU security team has predisclosed the following advisory:

    The AMD PC-Net II emulator(hw/net/pcnet.c), while receiving
    packets in loopback mode, appends CRC code to the receive
    buffer. If the data size given is same as the buffer size(4096),
    the appended CRC code overwrites 4 bytes after the s->buffer,
    making the adjacent 's->irq' object point to a new location.

IMPACT
======

A guest which has access to an emulated PCNET network device
(e.g. with "model=pcnet" in their VIF configuration) can exploit this
vulnerability to take over the qemu process elevating its privilege to
that of the qemu process.

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

All Xen systems running x86 HVM guests without stubdomains which have
been configured to use the PCNET emulated driver model are
vulnerable.

The default configuration is NOT vulnerable (because it does not
emulate PCNET NICs).

Systems running only PV guests are NOT 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" or upstream qemu device models are
potentially vulnerable.

ARM systems are NOT vulnerable.

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 PCNET device in favour of other emulations
will also avoid this issue.

Enabling stubdomains will mitigate this issue, by reducing the
escalation to only those privileges accorded to the service domain.

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

RESOLUTION
==========

The QEMU security team have supplied the attached xsa162-qemuu.patch
which it is believed will resolve the issue. However this patch has
not undergone the usual reviews and has not yet been accepted by QEMU
upstream.

The backports were created by the Xen Project security team on the same
basis.

xsa162-qemuu.patch           qemu upstream, Xen unstable, 4.6.x, 4.5.x, 4.4.x
xsa162-qemuu-4.3.patch       Xen 4.3.x
xsa162-qemut-4.3.patch       qemu-xen-traditional, Xen unstable, 4.5.x, 4.4.x, 4.3.x

$ sha256sum xsa162*
5844debcfdf606030aaa98f32a5920bc64c659dfae6062f24ab98e9008d8bf86  xsa162-qemut.patch
73e5857570b7464a2118a3ae6a8f424e01effd684c67773fada22a8411199238  xsa162-qemuu.patch
4a0ded68cc20d64752ef72e12983b20a4b14fef9b14e8774d889cfa34201909d  xsa162-qemuu-4.3.patch
$


CREDITS
=======

This issue was discovered by Qinghao Tang of the Qihoo 360 Marvel
Team.


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.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWXCrJAAoJEIP+FMlX6CvZEtkIAJJYN60maax4jOLKUNGJZcmO
MLTxucr4P2ffw5sNyNYJDHo7Ui5qTdx62uPQHAuYc8mt7x7g9+zhWH39XfFe/9KR
ZVqWAQeoFVT030dQXkuWQkr1ryXzWF/xIUzFsD4F0d3pXY3WNxTH5hKjmXxCUQzT
jM3h3hc4a2+BdTxL527liAiiG31z0sLMqop2V7346yqM5g+HK83DxN2hNackFWZx
PijuBIFO/L9FZiXvcsMtBllaHVko089MBtTF7nnOav1hJefn4yGDBdoj0D+r8PiB
6376dASIwznXV6YZcg62N2HxbKn4tnjr6HumM5kWlXUM7+f2eG3kfM4re7A3ry8=
=6xNZ
-----END PGP SIGNATURE-----

Download attachment "xsa162-qemut.patch" of type "application/octet-stream" (1744 bytes)

Download attachment "xsa162-qemuu.patch" of type "application/octet-stream" (1539 bytes)

Download attachment "xsa162-qemuu-4.3.patch" of type "application/octet-stream" (1531 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.