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

===========================================================================
             AUSCERT External Security Bulletin Redistribution

                               ESB-2015.1530
    Heap overflow in QEMU PCNET controller, allowing guest->host escape
                               12 June 2015

===========================================================================

        AusCERT Security Bulletin Summary
        ---------------------------------

Product:           Xen
Publisher:         Xen
Operating System:  Xen
                   UNIX variants (UNIX, Linux, OSX)
Impact/Access:     Execute Arbitrary Code/Commands -- Existing Account
Resolution:        Patch/Upgrade
CVE Names:         CVE-2015-3209  

Reference:         ESB-2015.1507

Original Bulletin: 
   http://xenbits.xen.org/xsa/advisory-135.html

- --------------------------BEGIN INCLUDED TEXT--------------------

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

            Xen Security Advisory CVE-2015-3209 / XSA-135
                              version 3

 Heap overflow in QEMU PCNET controller, allowing guest->host escape

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

Public release.

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

The QEMU security team has predisclosed the following advisory:

    pcnet_transmit loads a transmit-frame descriptor from the guest into the
    /tmd/ local variable to recover a length field, a status field and a
    guest-physical location of the associated frame buffer. If the status
    field indicates that the frame buffer is ready to be sent out (i.e. by
    setting the TXSTATUS_DEVICEOWNS, TXSTATUS_STARTPACKET and
    TXSTATUS_ENDPACKET bits on the status field), the PCNET device
    controller pulls in the frame from the guest-physical location to
    s->buffer (which is 4096 bytes long), and then transmits the frame.

    Because of the layout of the transmit-frame descriptor, it is not
    possible to send the PCNET device controller a frame of length > 4096,
    but it /is/ possible to send the PCNET device controller a frame that is
    marked as TXSTATUS_STARTPACKET, but not TXSTATUS_ENDPACKET. If we do
    this - and the PCNET controller is configured via the XMTRL CSR to
    support split-frame processing - then the pcnet_transmit functions loops
    round, pulling a second transmit frame descriptor from the guest. If
    this second transmit frame descriptor sets the TXSTATUS_DEVICEOWNS and
    doesn't set the TXSTATUS_STARTPACKET bits, this frame is appended to
    the s->buffer field.

    An attacker can then exploit this vulnerability by sending a first
    packet of length 4096 to the device controller, and a second frame
    containing N-bytes to trigger an N-byte heap overflow.

    On 64-bit QEMU, a 24-byte overflow allows the guest to take control of
    the phys_mem_write function pointer in the PCNetState_st structure, and
    this is called when trying to flush the updated transmit frame
    descriptor back to the guest. By specifying the content of the second
    transmit frame, the attacker therefore gets reliable fully-chosen
    control of the host instruction pointer, allowing them to take control
    of the host.

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.

CREDITS
=======

This issue was discovered by Matt Tait of Google and reported to us
via the QEMU security team.

RESOLUTION
==========

Applying the appropriate attached patch(es) resolves this issue.

xsa135-qemuu-unstable.patch  qemu-upstream, Xen unstable
xsa135-qemuu-4.5-*.patch     qemu-upstream, Xen 4.5.x, Xen 4.4.x
xsa135-qemuu-4.3-*.patch     qemu-upstream, Xen 4.3.x
xsa135-qemuu-4.2-*.patch     qemu-upstream, Xen 4.2.x
xsa135-qemut-*.patch         qemu-xen-traditional, Xen unstable, 4.5.x, 4.4.x, 4.3.x, 4.2.x

Note that the second patch for qemu-xen-traditional (all versions),
and qemu-upstream 4.3.x and 4.2.x are identical. Likewise
xsa135-qemuu-unstable.patch is the same as
xsa135-qemuu-4.5-2.patch. They are presented separately for
convenience.

$ sha256sum xsa135*.patch
a40897166f5de84c11b5d547191cd0375c7052edb0f44940eec7b78d839e447b  xsa135-qemut-1.patch
d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091  xsa135-qemut-2.patch
099693483d468a7fdecbf825635d3595ebeecc91c496624cbe109dcb4dd235da  xsa135-qemuu-unstable.patch
12ca5521f6bb1227934a1711d8adee11138a84c080a217f250efe34b3cb25b10  xsa135-qemuu-4.2-1.patch
d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091  xsa135-qemuu-4.2-2.patch
ad32c0ac145bc02b901c061fcbef83965f443fe89fcae9efc3b1dfd1e1d70bc8  xsa135-qemuu-4.3-1.patch
d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091  xsa135-qemuu-4.3-2.patch
baf9e0a960693b246ff01bb6210c5fee7713999d1e1b00a5b4e29d9ebd3c0ce8  xsa135-qemuu-4.5-1.patch
099693483d468a7fdecbf825635d3595ebeecc91c496624cbe109dcb4dd235da  xsa135-qemuu-4.5-2.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of patches or mitigations 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.

The decision not to permit deployment was made by the group that, at
their discretion, disclosed the issue to the Xen Project Security
Team.

Deployment is permitted only AFTER the embargo ends.

(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)

iQEcBAEBAgAGBQJVeDc3AAoJEIP+FMlX6CvZFBoIAJw/FxeABrdms6CzoxZxFQRp
It9eoMcmP+cxjMuAJyO771s+wYZy/X+ZDM2+CmzDWdBOzst3/YVw0ePbNH1T86y6
23Miqm5zupJ30xQGIXledrd/S23tmRlmzylytJcI9UQktuAOnL50l+wovKwhxVtO
x2Dg4P6RZ51twfbYLueIjBe2YSGGrck0kugpDtD6dH6kONNFgA+30i11Unwip18b
FzKm54b5HIvSoOkXCggCdgaCOmAuz3LpAt7FfB1324dPblxlfrDyRxWABxn47qoL
lgTJa7DPRTdxYM7EmnpMHKakgqzhD+Vu2Jnz8RELXt+AQH3TxRYXS2kT22QpfxY=
=cx83
- -----END PGP SIGNATURE-----

- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

        http://www.auscert.org.au/render.html?cid=1980

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967

iQIVAwUBVXo6rRLndAQH1ShLAQIXaBAAuO5UZZqyBZQx0ojdmd4mGuIR6AI6/E6+
8AR53B0Vpe5oP+l0osKp4AxQ1wyJi9CyPJ75Yl8vZzlVSEhM1aunAgOgEP9tWrD9
xvgrsygORNtsA/PAm3yH+YultK8zAAdq9017L/oRaewrpHYU9WRMJms+myZHs6ib
6sWBHkykJ6sui8H40ma2odVp9IM1Q5LmgjvHHht/3Q/h5Y0krUlZzawxPlBWrN1D
mndvV3dYv3nBujfrvd3/ou/4mn0hoLJ0Y7KOPsLnSXhpzKgmL40WhTTBPwyEBG1T
EvUKH92waohFk+xFr3TW+ZbvJrVJ/VweJ8wy6cIp+aihx3VY7pjYaKeKBjAtbRHS
vp1NW3I7rkES5JEsQgHMwrg2nRjcQAlXZhkY5i5kAENuQyuOHUQBAxHoX5zDn7Nh
zLIoL5nrx5nHUCVycJggIcEUVtboCaG2GkyXqNqmOeIfiWKzF1MA+uoPWkcDXLrp
ZazX9t0Eo69/+DjcP6iJpfjAnWBr1KIAzpYU5DsDKLEAVejSTvRPnoFi//TwGWWr
mdSQwe1NET/7RUp2A4noOgwFkOBVPc1YZgpd5C+B2UkHnJnby42sXQJ1fq91ysfj
XwkHWusVpOp6HRubYrLsFK1DSCO0SWT+lk0hR4S0FuhcriAX1ye2SKg43iamwzb5
nDyyRkaMTIk=
=7xAq
-----END PGP SIGNATURE-----