Information

Files

Advisory

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

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

         heap buffer overflow vulnerability in pcnet emulator

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

Normalize version tags.

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-xen master, 4.6.x, 4.5.x, 4.4.x
xsa162-qemuu-4.3.patch       qemu-xen 4.3.x
xsa162-qemut.patch           qemu-xen-traditional master, 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-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmV8b/EMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZlcsIAKXOILXQ6vUaDmdu+6TYB5d+Xq0NeXkjhTKxC9/S
suVp4o5GvC1J3S8XGThZyW+ueVoyqzb5aZNM//h48iH/dyPfaIXRSUbI/O5ro1yN
7B+YJ6penUn4QE/8HtGOKodu2BLm/MfQOnGH7FoO+Ib1OSBFQzF1qEUH1wRhhPKe
2BM/a7F0ioSe2NsXhEdvx0Z9Q+B807uB7asUIXWpeTrL54mCLpAhfWJsk5vqbrhT
lIarhaY26a5JYnGSae6APh+1g9vpo8owY5PUn74/GdwYxKN5qYEtx/69N1TJBIbG
JXBd2k6pc75DsOMAgnMLWD2+ksP1WA71ksek4aDJt1ifCtw=
=Zb4o
-----END PGP SIGNATURE-----