copyright | disclaimer | privacy | contact  
Australia's Leading Computer Emergency Response Team
 
Search this site

 
On this site

 > HOME
 > About AusCERT
 > Membership
 > Contact Us
 > PKI Services
 > Publications
 > Sec. Bulletins
 > Conferences
 > News & Media
 > Services
 > Web Log
 > Site Map
 > Site Help
 > Member login





 

ESB-2016.0416 - [UNIX/Linux][Virtual] Xen: Denial of service - Existing account

Date: 19 February 2016
References: ESB-2016.0717  ESB-2016.0803  ESB-2016.0862  ESB-2016.1675  

Click here for printable version
Click here for PGP verifiable version
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

                               ESB-2016.0416
                          Xen Security Advisories
                             19 February 2016

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

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

Product:           Xen
Publisher:         Xen
Operating System:  Xen
                   UNIX variants (UNIX, Linux, OSX)
Impact/Access:     Denial of Service -- Existing Account
Resolution:        Patch/Upgrade
CVE Names:         CVE-2016-2271 CVE-2016-2270 

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

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

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

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

            Xen Security Advisory CVE-2016-2270 / XSA-154
                              version 3

          x86: inconsistent cachability flags on guest mappings

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

Clarify cumbersome Resolution wording.

The patch now adds a command line option to overcome the possible
performance regression.  Add patch backports.

Clarify origin of assertion (at start of patch description) that
inconsistent cacheability is a problem only for mmio pages.

Public release.

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

Multiple mappings of the same physical page with different cachability
setting can cause problems.  While one category (risk of using stale
data) affects only guests themselves (and hence avoiding this can be
left for them to control), the other category being Machine Check
exceptions can be fatal to entire hosts.  According to the information
we were able to gather, only mappings of MMIO pages may surface this
second category, but even for them there were cases where the
hypervisor did not properly enforce consistent cachability.

IMPACT
======

A malicious guest administrator might be able to cause a reboot,
denying service to the entire host.

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

All Xen versions are affected.

Only x86 guests given control over some physical device can trigger
this vulnerability.

x86 systems are vulnerable.  ARM systems are not vulnerable.

The vulnerability depends on the system response to mapping the same
memory with different cacheability.  On some systems this is harmless;
on others, depending on CPU and chipset, it may be fatal.

MITIGATION
==========

Not handing physical devices to guests will also avoid this issue.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

We believe that the attached patch fixes the issue.  However, no
formal description of CPU behaviour in particular use cases has been
provided by Intel.  There has been no response from AMD.

We are aware of a potential performance regression with this patch on
some systems - even if no hardware passthrough is configured.  This is
due to the behaviour of some drivers and peripherals that is beyond
the scope of this security fix.  The patch adds a command line option
"mmio-relax" to overcome this possible regression for Domain 0 or all
para-virtual guests.  Note however that enabling this workaround will
reinstate the security issue these patches aim to address.

xsa154.patch        xen-unstable
xsa154-4.6.patch    Xen 4.6.x
xsa154-4.5.patch    Xen 4.5.x
xsa154-4.4.patch    Xen 4.4.x
xsa154-4.3.patch    Xen 4.3.x

$ sha256sum xsa154*
bbe7fba38ee30c00ef850fa6419c769e88b5669164d447f50b1ebbe333573152  xsa154.patch
011a4e33c0e476c52fe44253d50e01a1185948fd1b2a8e645274b25da6030d71  xsa154-4.3.patch
92d475bbc344127faa4f0183a9ccca9e975c7d24eb5772bf0a0a0a2e019144c6  xsa154-4.4.patch
b13737e71f22185b94ab25c07afd521add1a7e3886326c719d5df4d42f3f87f4  xsa154-4.5.patch
eec88c2a57466f83a81844cb7025f70c2b671d07a75d85487d4ed73cdabbb020  xsa154-4.6.patch
$

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 the configuration change would 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)

iQEcBAEBAgAGBQJWxGayAAoJEIP+FMlX6CvZ9KwH/3z+9b7OjgpuIsOf0giZ5y99
yKoORWxQjcosYLQRQXvH62xtz0xRng+E3p+MeUm2qPUUuHFiqxSpZOAvW61C6DQL
l5KNNHlIjWB3N0YVmvgRbf3WMbeX1DCsEJEIFxZUQQs3fgGAiOfIEOwRL2FIhJ5Y
wP/z59fCuWs5lHoV0iAY3gkZHDd09JspCRQq8UGAc+X5jHF6fIOhUjZCS9KRQMJ5
p69ysdMj96fY5eKqwka/EXzvKMJUsQ42u5RQoYR5FhLx1UBi2otdcdbloKNseksA
7Wbf6j8Mz9NWVhvdZtnR/CNH8m5V7d78HsnGv7zNQCiMW+wg/k53yzHcw550P4w=
=5V3D
- -----END PGP SIGNATURE-----

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

            Xen Security Advisory CVE-2016-2271 / XSA-170
                              version 3

      VMX: guest user mode may crash guest with non-canonical RIP

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

Public release.

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

VMX refuses attempts to enter a guest with an instruction pointer which
doesn't satisfy certain requirements.  In particular, the instruction
pointer needs to be canonical when entering a guest currently in 64-bit
mode.  This is the case even if the VM entry information specifies an
exception to be injected immediately (in which case the bad instruction
pointer would possibly never get used for other than pushing onto the
exception handler's stack).  Provided the guest OS allows user mode to
map the virtual memory space immediately below the canonical/non-
canonical address boundary, a non-canonical instruction pointer can
result even from normal user mode execution. VM entry failure, however,
is fatal to the guest.

IMPACT
======

Malicious HVM guest user mode code may be able to crash the guest.

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

All Xen versions are affected.

Only systems using Intel or Cyrix CPUs are affected. ARM and AMD
systems are unaffected.

Only HVM guests are affected.

MITIGATION
==========

Running only PV guests will avoid this vulnerability.

Running HVM guests on only AMD hardware will also avoid this
vulnerability.

CREDITS
=======

This issue was discovered by Ling Liu of Qihoo 360 Inc.

RESOLUTION
==========

Applying the appropriate attached patch works around this issue.  Note
that it does so in a way which isn't architecturally correct, but no
better solution has been found (nor suggested by Intel).

xsa170.patch           xen-unstable, Xen 4.6.x
xsa170-4.5.patch       Xen 4.5.x, Xen 4.4.x
xsa170-4.3.patch       Xen 4.3.x

$ sha256sum xsa170*
77b4b14b2c93da5f68e724cf74e1616f7df2e78305f66d164b3de2d980221a9a  xsa170.patch
b35679bf7a35615d827efafff8d13c35ceec1184212e3c8ba110722b9ae8426f  xsa170-4.3.patch
1df068fb439c7edc1e86dfa9ea3b9ae99b58cdc3ac874b96cdf63b26ef9a6b98  xsa170-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
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWxGa0AAoJEIP+FMlX6CvZ3rkIAIo+pvKqkNbHjalgGpP4BVe7
+7tuVnL74wt5Dt4AuOFyPLnEaHbp5UkIKK++eP/urFCz5+/LbOqcWnfiQdWMLQ/t
17NX2CMSYUCwUAkMMjvbKvGM3W8AJ85naIQho9KQSPbY1/Q51jDS5bLT06B2iRr4
njML2ii2OhOTGAvC2XmnidFNvLGQxlfeeC75O9dbCFENSYn5WbdmHonTnK8qm22H
eEvLlzg4D6yAmEaqHHZJ3bz1qtTw5FDNm/0tdZ1LO7lMuK01nMHSMmWG/Agc7219
lQH22N0+YTtgQKf65QciEThEnvTeDpeq84m64GqVhwzwssl1JrywrSsVkaQOnKA=
=Ca+d
- -----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

iQIVAwUBVsZqk36ZAP0PgtI9AQIPuRAAtqJ6QBG9O+Qqtqhs9fQ5WkVWq681GNCC
/puNpiIRXazNBy3SQEj26f9jaVDQ4Y19iNIdHe7addJtJq8cXWEukDk7alw5bi3k
4rdAHVEigoinTrdh6QOBD7VG6ExbbsxszBorqwQpWZsRmN7JEtMMB9TRThmEWAZ8
eDjx9ohLbvoAqv9zYcdq2I3lkAjCwnP5tFAkeK+kYipW2Bc/PQOgLQcEriwDq39R
UFPGWdQ9LBoJCwQBjZgBMOQ70fb8gvdEOrUSpIKc8VM79dxvOPa437hJc0EUIcwm
LyFZjE+r4ix4BVNRjbxDefUNqzpvXEn7Lfv4moB2qnPEMDQaGADHqzdys6ES+3Hy
GdSiZt1XA1OhvKHAt+/m+o2ZRrbbvS1qLJ9mwmyGBJFaRQqGacmas9LO1sy1d0e0
mIKLqLyzKA8LO+V4yqKc6nydCzrBqrY5oF/oQWnBjs+wRv8VZt0MBPKnaTkOb+6C
rvEJLpmppGDMfxMy6QSKA7WQltXGEVMBh60XLLroULdGzyMsey7FMhVWxZ7t1jBw
pNECLtY7YaeZHtcY2UPnFL4pbqRdM9v1n3IRVUSmRWhNK+IDAMK3a2VzXhy5yrLn
G4+epLMREM7KFbkr++JC/bUFy+qFOiAg0us7eCnBMfONZ2AYwTai1hKOIMHvy4yH
gormgqB5+vI=
=DyKF
-----END PGP SIGNATURE-----