Bug 615980 – app-emulation/{xen-4.7.2-r1,{xen-pvgrub,sen-tools}-4.7.2}: Multiple Vulnerabilities (XSA-{213,214,215})

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description Yury German 2017-04-18 22:07:19 UTC]

Xen Security Advisory XSA-215

           possible memory corruption via failsafe callback

              *** EMBARGOED UNTIL 2017-05-02 12:00 UTC ***

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

Under certain special conditions Xen reports an exception resulting
from returning to guest mode not via ordinary exception entry points,
but via a so call failsafe callback.  This callback, unlike exception
handlers, takes 4 extra arguments on the stack (the saved data
selectors DS, ES, FS, and GS).  Prior to placing exception or failsafe
callback frames on the guest kernel stack, Xen checks the linear
address range to not overlap with hypervisor space.  The range spanned
by that check was mistakenly not covering these extra 4 slots.

IMPACT
======

A malicious or buggy 64-bit PV guest may be able to modify part of a
physical memory page not belonging to it, potentially allowing for all
of privilege escalation, host or other guest crashes, and information
leaks.

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

64-bit Xen versions 4.6 and earlier are vulnerable.  Xen versions 4.7
and later are not vulnerable.

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

Only x86 systems with physical memory extending to a configuration
dependent boundary (5Tb or 3.5Tb) may be affected.  Whether they are
actually affected depends on actual physical memory layout.

The vulnerability is only exposed to 64-bit PV guests.  HVM guests and
32-bit PV guests can't exploit the vulnerability.

MITIGATION
==========

Running only HVM or 32-bit PV guests will avoid the vulnerability.

The vulnerability can be avoided if the guest kernel is controlled by
the host rather than guest administrator, provided that further steps
are taken to prevent the guest administrator from loading code into
the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa215.patch       Xen 4.6.x, Xen 4.5.x

$ sha256sum xsa215*
d45a5956a397b80077c322d4c9ed806190a1219676e6bedd1c665d54f60bd672  xsa215.patch
$

[Comment 1 Yury German 2017-04-18 22:20:47 UTC]

 Xen Security Advisory XSA-213

   x86: 64bit PV guest breakout via pagetable use-after-mode-change

              *** EMBARGOED UNTIL 2017-05-02 12:00 UTC ***

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

64-bit PV guests typically use separate (root) page tables for their
kernel and user modes.  Hypercalls are accessible to guest kernel
context only, which certain hypercall handlers make assumptions on.
The IRET hypercall (replacing the identically name CPU instruction)
is used by guest kernels to transfer control from kernel mode to user
mode.  If such an IRET hypercall is placed in the middle of a multicall
batch, subsequent operations invoked by the same multicall batch may
wrongly assume the guest to still be in kernel mode.  If one or more of
these subsequent operations involve operations on page tables, they may
be using the wrong root page table, confusing internal accounting.  As
a result the guest may gain writable access to some of its page tables.

IMPACT
======

A malicious or buggy 64-bit PV guest may be able to access all of
system memory, allowing for all of privilege escalation, host crashes,
and information leaks.

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

All 64-bit Xen versions are vulnerable.

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

The vulnerability is only exposed to 64-bit PV guests.  HVM guests and
32-bit PV guests can't exploit the vulnerability.

MITIGATION
==========

Running only HVM or 32-bit PV guests will avoid the vulnerability.

The vulnerability can be avoided if the guest kernel is controlled by
the host rather than guest administrator, provided that further steps
are taken to prevent the guest administrator from loading code into
the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa213.patch           xen-unstable
xsa213-4.8.patch       Xen 4.8.x
xsa213-4.7.patch       Xen 4.7.x
xsa213-4.6.patch       Xen 4.6.x
xsa213-4.5.patch       Xen 4.5.x

$ sha256sum xsa213*
13eab7369f8c4eed3398fe8b478db431cfed31f737e455be7d7af4ebe273b951  xsa213.patch
6f808e597d4996323078c9954d321c0da7375c9c65bda5c37a8d08b10e7d3cc4  xsa213-4.5.patch
cbd78eb154e90e36cdd5ffc0d95ef0a787d5f9a63012fe2329f00df38e75af3f  xsa213-4.6.patch
8311acc09d2a3037bc2ac9102b9dfe5222b30ea04c7b3fa0e21897eaae35e17b  xsa213-4.7.patch
1b7364b92073abfd7614742a38d38113cbaab30d0132f23527fc09cab100e7f3  xsa213-4.8.patch

______________________________

Xen Security Advisory XSA-214

         grant transfer allows PV guest to elevate privileges

              *** EMBARGOED UNTIL 2017-05-02 12:00 UTC ***

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

The GNTTABOP_transfer operation allows one guest to transfer a page to
another guest.  The internal processing of this, however, does not
include zapping the previous type of the page being transferred.  This
makes it possible for a PV guest to transfer a page previously used as
part of a segment descriptor table to another guest while retaining the
"contains segment descriptors" property.

If the destination guest is a PV one of different bitness, it may gain
access to segment descriptors it is not normally allowed to have, like
64-bit code segments in a 32-bit PV guest.

If the destination guest is a HVM one, that guest may freely alter the
page contents and then hand the page back to the same or another PV
guest.

In either case, if the destination PV guest then inserts that page into
one of its own descriptor tables, the page still having the designated
type results in validation of its contents being skipped.

IMPACT
======

A malicious pair of guests may be able to access all of system memory,
allowing for all of privilege escalation, host crashes, and information
leaks.

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

All Xen versions are vulnerable.

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

MITIGATION
==========

Running only one out of the three relevant classes of guest (namely:
32-bit PV; 64-bit PV; HVM) on any given host will avoid the
vulnerability.  (Note that this must also include any nonprivileged
service domains such as stub device model domains.)

The vulnerability can also be avoided if all guest kernels are
controlled by the host rather than guest administrator, provided that
further steps are taken to prevent the guest administrator from loading
code into the kernel (e.g. by disabling loadable modules etc) or from
using other mechanisms which allow them to run code at kernel privilege.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa124.patch           xen-unstable, Xen 4.8.x, 4.7.x, 4.6.x, 4.5.x

$ sha256sum xsa214*
a4d28075950ffd43240bf24e531334273a6324fefc214c67735af60d54717b2d  xsa214.patch

[Comment 2 Yixun Lan 2017-05-03 01:43:44 UTC]

commit 2b588317631794ae65bd1eb7580c4c1741cdf3da
Author: Yixun Lan <[e-mail]>
Date:   Wed May 3 09:40:40 2017 +0800

    app-emulation/xen: security bump
    
    Fix XSA-213, 214, 215
    
    Gentoo-Bug: 615980
    Package-Manager: Portage-2.3.5, Repoman-2.3.2


https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2b588317631794ae65bd1eb7580c4c1741cdf3da

[Comment 3 Yixun Lan 2017-05-03 01:46:19 UTC]

Arches, please test and mark stable:
=app-emulation/xen-4.7.2-r1
Target keyword only: "amd64" 

=app-emulation/xen-pvgrub-4.7.2
=app-emulation/xen-tools-4.7.2
Target keywords: "amd64 x86"

[Comment 4 Agostino Sarubbo 2017-05-10 09:33:21 UTC]

amd64 stable

[Comment 5 Agostino Sarubbo 2017-05-10 15:45:18 UTC]

x86 stable.

Maintainer(s), please cleanup.
Security, please add it to the existing request, or file a new one.

[Comment 6 Yixun Lan 2017-05-11 10:29:28 UTC]

dropped all vulnerable versions, thanks


commit c9b91732aa0d6c666cb768053f0f1070f35b00c9
Author: Yixun Lan <[e-mail]>
Date:   Thu May 11 18:13:28 2017 +0800

    app-emulation/xen-tools: cleanup, drop old vulnerables


commit 6cc42142309ed9157a4069a8de0120dbd4aa75e2
Author: Yixun Lan <[e-mail]>
Date:   Thu May 11 18:02:35 2017 +0800

    app-emulation/xen: cleanup, drop old vulnerables


https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c9b91732aa0d6c666cb768053f0f1070f35b00c9
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6cc42142309ed9157a4069a8de0120dbd4aa75e2

[Comment 7 GLSAMaker/CVETool Bot 2017-05-26 06:27:03 UTC]

This issue was resolved and addressed in
 GLSA 201705-11 at https://security.gentoo.org/glsa/201705-11
by GLSA coordinator Thomas Deutschmann (whissi).