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

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

                               ESB-2014.0403
          A number of vulnerabilities have been identified in Xen
                               27 March 2014

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

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

Product:           Xen
Publisher:         Xen
Operating System:  Xen
                   UNIX variants (UNIX, Linux, OSX)
Impact/Access:     Denial of Service -- Remote/Unauthenticated
Resolution:        Patch/Upgrade

Original Bulletin: 
   http://xenbits.xenproject.org/xsa/advisory-89.html
   http://xenbits.xenproject.org/xsa/advisory-90.html

Comment: This bulletin contains two (2) Xen security advisories.

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

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

                    Xen Security Advisory XSA-89
                             version 2

              HVMOP_set_mem_access is not preemptible

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

Public release.

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

Processing of the HVMOP_set_mem_access HVM control operations does not
check the size of its input and can tie up a physical CPU for extended
periods of time.

IMPACT
======

In a configuration where device models run with limited privilege (for
example, stubdom device models), a guest attacker who successfully
finds and exploits an unfixed security flaw in qemu-dm could leverage
the other flaw into a Denial of Service affecting the whole host.

In the more general case, in more abstract terms: a malicious
administrator of a domain privileged with regard to an HVM guest can
cause Xen to become unresponsive leading to a Denial of Service.

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

All Xen versions from 4.1 onwards are vulnerable. In 4.2 only 64-bit
versions of the hypervisor are vulnerable (HVMOP_set_mem_access is not
available in 32-bit hypervisors).

The vulnerability is only exposed to service domains for HVM guests
which have privilege over the guest.  In a usual configuration that
means only device model emulators (qemu-dm).

In the case of HVM guests whose device model is running in an
unrestricted dom0 process, qemu-dm already has the ability to cause
problems for the whole system.  So in that case the vulnerability is
not applicable.

The situation is more subtle for an HVM guest with a stub qemu-dm.
That is, where the device model runs in a separate domain (in the case
of xl, as requested by "device_model_stubdomain_override=1" in the xl
domain configuration file).  The same applies with a qemu-dm in a dom0
process subjected to some kind kernel-based process privilege
limitation (eg the chroot technique as found in some versions of
XCP/XenServer).

In those latter situations this issue means that the extra isolation
does not provide as good a defence (against denial of service) as
intended.  That is the essence of this vulnerability.

However, the security is still better than with a qemu-dm running as
an unrestricted dom0 process.  Therefore users with these
configurations should not switch to an unrestricted dom0 qemu-dm.

Finally, in a radically disaggregated system: where the HVM service
domain software (probably, the device model domain image) is not
always supplied by the host administrator, a malicious service domain
administrator can excercise this vulnerability.

MITIGATION
==========

Running only PV guests will avoid this vulnerability.

In a radically disaggregated system, restricting HVM service domains
to software images approved by the host administrator will avoid the
vulnerability.

CREDITS
=======

This issue was discovered by Jan Beulich.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa89.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x
xsa89-4.1.patch    Xen 4.1.x

$ sha256sum xsa89*.patch
741c8fbbfa8e425d8debba17135d4c2e1e962d15717769bc93d68a65b5dc5ea6  xsa89.patch
7d965e9bf1894b7d909bfaddbc6b7bdcee0ba91b86942ce85e0ae80464f2463e  xsa89-4.1.patch
$
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJTMXLgAAoJEIP+FMlX6CvZZ78H/RbnQJwEHxKxn3zhaEULpm57
zBPG1D2cGP12UCkFQLqR8tWvPYmEtm3/x/FQHjzTCBBCM3GMFJ9BiKOX+u5+h2Bu
17xPD3K8cH1tBkZpnQTkTBTz7XrfwV+C78kaNxo3TBvlgTIljaGCHxkXt0PmR1Vq
DPZEQdYXj/v8pblmyHYuhd6zf3n6V07ABLqHyPc9n6yZ4/o2LFjqQPZJpYFiFZI+
NGPw18+WCYlXc9w9ZtpGlNOo7Y5O2lraLLu7Gyi+JjC/BHXnb1XLgmgOSTyj2X5M
5v6zIMXy3vqaXHyjqw7uX6EzhCPfPhXAXVjpVGDin+RY/Ykp0QBDweUxZb4U71U=
=u+aG
- -----END PGP SIGNATURE-----

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

                    Xen Security Advisory XSA-90

      Linux netback crash trying to disable due to malformed packet

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

When Linux's netback sees a malformed packet, it tries to disable the
interface which serves the misbehaving frontend.

This involves taking a mutex, which might sleep.  But in recent
versions of Linux the guest transmit path is handled by NAPI in
softirq context, where sleeping is not allowed.  The end result is
that the backend domain (often, Dom0) crashes with "scheduling while
atomic".

IMPACT
======

Malicious guest administrators can cause denial of service.  If driver
domains are not in use, the impact is a host crash.

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

This bug affects systems using Linux as the driver domain, including
non-disaggregated systems using Linux as dom0.

Only versions of Linux whose netback uses NAPI are affected.  In Linux
mainline this is all versions of Linux containing git changeset
b3f980bd82, which was introduced between Linux 3.11 and 3.12-rc1.

Systems using a different OS as dom0 (eg, NetBSD, Solaris) are not
vulnerable.

Both x86 and ARM systems are affected.

MITIGATION
==========

Using driver domains may limit the scope of the denial of service, and
may make it possible to resume service without restarting guests (by
restarting the driver domain).  Advice on reconfiguring a system to
use driver domains is beyond the reasonable scope of this advisory.

In the case of an x86 HVM guest, the exploit can be prevented by
disabling the PV IO paths; normally this would come with a substantial
performance cost, and it may involve reconfiguring the guest as well
as the host.  This is not recommended.

NOTE REGARDING LACK OF EMBARGO
==============================

This bug was publicly reported on xen-devel, before it was appreciated
that there was a security problem.  The public mailing list thread
nevertheless contains information strongly suggestive of a security
bug, and a different security bug (with CVE) is suggested as seeming
"similar".

For these reasons we (the Xen Project Security Team) have concluded
that the presence of this bug, as a security problem, is not (any
longer) a secret.

CREDITS
=======

This issue was discovered as a bug by Török Edwin and analysed by
Wei Liu of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

$ sha256sum xsa90*.patch
07341ffb7f577d32510602797a08009eade817009b425a124413ee743bdb6f05  xsa90.patch
$
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJTMCxRAAoJEIP+FMlX6CvZaAEIAIIVfNdz3CwFYbiSwa51RJ3L
YFarP71/0EjNJKSaRwf6EQjDNnApqq6ep4+WKFvlMbm515jyQXp6mAbb8ffqnLUQ
2SDOlQXOpbnZrJrgo4YcT5ru8ZusauYz36TkFVcXBmcKWq29KoUARo5zG7YGyh9H
aWajaZs6RQPv3QE8IInNSP0oitRQZg/5xAW+Lz4Kn8xpO/IJuYW3ROH6JQcFF67H
r7xVAzxjrNQ3P5mN0iiOkQYK39PqhwGUhWaa6JlejsjUgU1nsGIBOHH+ISCaZrtL
e/6XK3awaDiu1dAL4Py1SdhPiA0sTeqA3bf6ARd7ymoIFqGuxrqYlupcUKTupjE=
=LrLN
- -----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

iQIVAwUBUzO+DhLndAQH1ShLAQJC/w//bGBIrf0Rre5XNdxu+P5idlmo28VQ2/l6
p7R1kI9KzZ6E3n8kO7VnIr0jT75+Q3Hr4bNheX2uUbblvFeL2LzLdyi3GVN1UmO7
hyGLEdBoEZRhCE5wRnf5FWMxEuKfQ+iSpL1rTCbBCDCI4aYmR/x93wI7gnrFFss/
AwlU8zxZzSL1ArtimaxyMEMXk/wf5zw28XscefPCh9kJa3YSsAk/FPylPSZNXRMe
QW8hWtvgST/r/hMxJiDIy1oOLAFNROTMjkoHrDn1K2l1n6oHgq8kvmBmYQyic4jy
+Euoa1KO139yhhLgS9Gu4xirFp8DlwNtlK8xxycN6jy0QrH7yq27mkFs/ooPRAS0
b7lPvg0zcSINZ436kZLYb6RDECcsiS8bIkRHRPTfgjV4OFB2AEtQS02jUq9t+XhR
EM+gxXK1IUdKH/akJdQvnEIGjF4Z8Gmz3RZG/S/aToGy4UC9l2ROhIF8stQ6UpMQ
fb3MfBLEvQLQQ9dnz77jVmtKO2+ajc/lZ5durveN/OpUF69d1ny5WKbz8+O+sIbz
rAt8fVP01Hov3A/fsDgUNF0u2ohtwXYb9s3EyG/U8hliJubDNKYwbfw5a1KqtoC2
BfqX6sWRArHgOZABG6ht4oenrFXVtDct0eUXm7mHxHZ7XXna453oy78WCqJHpYP3
Eeu/hXmMl8A=
=8rm9
-----END PGP SIGNATURE-----