| Summary: | app-emulation/{xen-4.7.2-r1,{xen-pvgrub,sen-tools}-4.7.2}: Multiple Vulnerabilities (XSA-{213,214,215}) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Yury German <blueknight> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dlan, gentoo |
| Priority: | Normal | Flags: | blueknight:
sanity-check+
|
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | B2 [glsa cve] | ||
| Package list: |
=app-emulation/xen-4.7.2-r1
=app-emulation/xen-pvgrub-4.7.2
=app-emulation/xen-tools-4.7.2
|
Runtime testing required: | --- |
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
commit 2b588317631794ae65bd1eb7580c4c1741cdf3da Author: Yixun Lan <dlan@gentoo.org> 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 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" amd64 stable x86 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one. dropped all vulnerable versions, thanks commit c9b91732aa0d6c666cb768053f0f1070f35b00c9 Author: Yixun Lan <dlan@gentoo.org> Date: Thu May 11 18:13:28 2017 +0800 app-emulation/xen-tools: cleanup, drop old vulnerables commit 6cc42142309ed9157a4069a8de0120dbd4aa75e2 Author: Yixun Lan <dlan@gentoo.org> 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 This issue was resolved and addressed in GLSA 201705-11 at https://security.gentoo.org/glsa/201705-11 by GLSA coordinator Thomas Deutschmann (whissi). |
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 $