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

                             CERT-Renater

                 Note d'Information No. 2018/VULN082
_____________________________________________________________________

DATE                : 28/02/2018

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running Xen.

=====================================================================
https://xenbits.xen.org/xsa/advisory-252.html
https://xenbits.xen.org/xsa/advisory-255.html
https://xenbits.xen.org/xsa/advisory-256.html
_____________________________________________________________________


                    Xen Security Advisory XSA-252
                              version 2

             DoS via non-preemptable L3/L4 pagetable freeing

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

Public release.

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

Guests have the ability to request removal of memory from themselves.
This operation is intended to be requested for normal read/write pages,
but is also permitted to be used on other types of pages.  So far this
in particular included pages pinned to their current type, with the
necessary unpinning happening implicitly.  The unpinning of higher level
page tables can, however, take a significant amount of time, and hence
is generally expected to be carried out with intermediate preemption
checks.  Such checks were missing from the code path involved here.

IMPACT
======

A malicious guest administrator can cause a Denial of Service (DoS).
Specifically, prevent use of a physical CPU for a significant period of
time.

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

All Xen versions are vulnerable.

Only x86 systems are affected.  ARM systems are not affected.

Only PV guests can leverage this vulnerability.  HVM guests cannot
leverage this vulnerability.

MITIGATION
==========

Running only HVM guests will avoid this issue.

CREDITS
=======

This issue was discovered by Jann Horn of Google Project Zero.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa252.patch           xen-unstable, Xen 4.10.0
xsa252-4.9.patch       Xen 4.9.x, Xen 4.8.x
xsa252-4.7.patch       Xen 4.7.x
xsa252-4.6.patch       Xen 4.6.x, Xen 4.5.x

$ sha256sum xsa252*
5bf651378b92520969cde49d11500bcaeffab15590d21c16736be408a85ab3fa
xsa252.meta
53174dfd05eb274431dc756c9c3a39b355d485d6c9d12a8797b350bab343d22e
xsa252.patch
b7ba005fa62ace07f4880cc79824968c24ead3182245e4ed3a6e22cf8d2d7c05
xsa252-4.6.patch
14f37eb6b7a9fb19b258ca3c0e2da71dbc4240e6273137d5eb4003b122101aa6
xsa252-4.7.patch
cb679f2145e76b1c754c4377b397d201007f50438ee18e451c4b0da3f510a293
xsa252-4.9.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

_____________________________________________________________________

                    Xen Security Advisory XSA-255
                              version 3

             grant table v2 -> v1 transition may crash Xen

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

Public release.

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

Grant tables come in two flavors (versions), and domains are permitted
to freely change between them (subject to certain constraints).  For
the guest to use the facility, both the "normal" shared pages
(applicable to v1 and v2) and the "status" pages (applicable to v2
only) need to be mapped by the guest into its address space.

When transitioning from v2 to v1, the status pages become unnecessary
and are therefore freed by Xen.  That means Xen needs to check that
there are no mappings of those pages by the domain.  However, that
check was mistakenly implemented as a bug check, rather than returning
an error to the guest.

IMPACT
======

A malicious or buggy guest may cause a hypervisor crash, resulting in
a Denial of Service (DoS) affecting the entire host.  Privilege
escalation as well as information leaks cannot be ruled out for HVM,
PVH (both x86), and ARM guests.

The impact is more severe for Xen versions 4.0.x, 4.1.0 ... 4.1.3, and
4.2 in that the pages are freed without any checking, thus allowing
their re-use for another domain, or by Xen itself, while there still
are active mappings (see XSA-26).

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

Xen versions 4.0 and newer are vulnerable.

Both x86 and ARM systems are vulnerable.

MITIGATION
==========

Using the "gnttab=max_ver:1" hypervisor command line option, where
available, to disable use of v2 grant tables allows to avoid the
vulnerability.  Use of this option will, however, break any guests which
require to make use of v2 functionality.  The patch introducing this
option was not merged so far, but is available (in its current form) at
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00059.html
("common/gnttab: Introduce command line feature controls").

There is no other known mitigation.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa255-?.patch         xen-unstable, Xen 4.10.x
xsa255-4.9-?.patch     Xen 4.9.x, Xen 4.8.x
xsa255-4.7-?.patch     Xen 4.7.x
xsa255-4.6-?.patch     Xen 4.6.x

$ sha256sum xsa255*
05a5570ecf4354f7aad35bb77a4c2f5f556bcabf3555829a98c94dcfb6dd4696
xsa255-1.patch
df43a147f1e1a2b7d59588bc91cdaac05d4e45bcfc4e2c8cb5e8de840d44b43d
xsa255-2.patch
be62d81583df10a6be275427d5cfa02084c8717473b3694cd2a9bbdc10cbadcb
xsa255-4.6-1.patch
3dd58114c5ce68fd8dd43f8f92eaafdcec1fd9add37eb41faed1cf818058539a
xsa255-4.6-2.patch
9bfc4a33a0faeb36aec8449ea940cef52d523cc3d13529b4eeaae64bf5a7b644
xsa255-4.7-1.patch
6d95ceb54298de7863dc7133c0f3adf85f7da9b8d326146ff46e641194a47fc0
xsa255-4.7-2.patch
0b4706f0d2d21d4f6414ae9c0205e553bfb792c23d44e129b3a0f90be557d13f
xsa255-4.9-1.patch
9c6b2d2183ffa484182ca75e1a048d0713c4d150e750ccf58be5a24991a3e1de
xsa255-4.9-2.patch
$

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

Deployment of the patches 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 mitigation 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 this produces a guest-visible
change which will indicate which component contains the vulnerability.

Additionally, 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

_____________________________________________________________________


                    Xen Security Advisory XSA-256
                              version 2

             x86 PVH guest without LAPIC may DoS the host

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

Public release.

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

So far, x86 PVH guests can be configured with or without Local APICs.
Configurations with Local APICs are identical to x86 HVM guests, and
will use as much hardware acceleration support as possible.
Configurations without Local APICs try to turn off all hardware
acceleration, and disable all software emulation.

Multiple paths in Xen assume the presence of a Local APIC without
sufficient checks, and can fall over a NULL pointer.  On Intel hardware,
the logic to turn off hardware acceleration is incomplete and leaves the
guest with full control of the real Task Priority Register.

IMPACT
======

A malicious or buggy guest may cause a hypervisor crash, resulting in
a Denial of Service (DoS) affecting the entire host.

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

Xen version 4.8 and onwards are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

Only x86 PVH guests can exploit the vulnerability.  x86 PV and HVM
guests cannot exploit the vulnerability.

MITIGATION
==========

Running only PV or HVM guests avoids the vulnerability.

Running all PVH guests with "apic=1" in the guest configuration file
(or equivalent thereof) also avoids the vulnerability.

CREDITS
=======

This issue was discovered by Ian Jackson of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa256.patch           xen-unstable, Xen 4.10.x, Xen 4.9.x
xsa256-4.8.patch       Xen 4.8.x

$ sha256sum xsa256*
3e45cc3f2ea516e7470083592041e238c0dfe32324790b2fba0e47c9efe38865
xsa256.patch
c029fcb67ff7c3c9a2adcb8e6f5e245a0d347acc8a9b3530591a639cbf321349
xsa256-4.8.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


==========================================================
+ CERT-RENATER          | tel : 01-53-94-20-44           +
+ 23 - 25 Rue Daviel    | fax : 01-53-94-20-41           +
+ 75013 Paris           | email: cert@support.renater.fr +
==========================================================