Bug 679580 – <app-emulation/xen{-tools,-pvgrub}-4.10.3-r2: multiple vulnerabilities

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description Tomáš Mózes 2019-03-06 08:42:52 UTC]

http://xenbits.xen.org/xsa/

XSA-284-288 + 290-294

[Comment 1 Tomáš Mózes 2019-03-06 08:43:18 UTC]

https://github.com/gentoo/gentoo/pull/11278

[Comment 2 Tomáš Mózes 2019-03-07 14:27:20 UTC]

Please call stabilization,fixed versions in tree. Thanks.

[Comment 3 Yixun Lan 2019-03-08 03:49:26 UTC]

 Arches, please test and mark stable:
=app-emulation/xen-4.10.3-r1
Target keyword only: "amd64" 
         
=app-emulation/xen-pvgrub-4.10.3
=app-emulation/xen-tools-4.10.3-r1
Target keywords: "amd64 x86"

[Comment 4 Mikle Kolyada (RETIRED) 2019-03-08 12:38:57 UTC]

amd64 stable

[Comment 5 Yury German 2019-03-09 17:01:23 UTC]

Xen Security Advisory XSA-284
                              version 2

              grant table transfer issues on large hosts

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

Metadata updated to remove dependency on XSA-283.

Public release.

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

When the code processing grant table transfer requests finds a page with
an address too large to be represented in the interface with the guest,
it allocates a replacement page and copies page contents.  However, the
code doing so fails to set the newly allocated page's accounting
properties correctly, resulting in the page becoming not only unusable
by the target domain, but also unfreeable upon domain cleanup.  The page
as well as certain other remnants of an affected guest will be leaked.

Furthermore internal state of the processing code was also not updated
correctly, resulting in the insertion of an IOMMU mapping to the page
being replaced (and subsequently freed), allowing the domain access to
memory it does not own.

IMPACT
======

The primary impact is a memory leak.  Malicious or buggy guests with
passed through PCI devices may also be able to escalate their
privileges, crash the host, or access data belonging to other guests.

______________________________

Xen Security Advisory XSA-285
                              version 2

                 race with pass-through device hotplug

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

Metadata updated to remove dependency on XSA-283.

Public release.

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

When adding a passed-through PCI device to a domain after it was already
started, IOMMU page tables may need constructing on the fly.  For PV
guests the decision whether a page ought to have a mapping is based on
whether the page is writable, to prevent IOMMU access to things like
page tables.  Writablility of a page may, however, change at any time.
Failure of the relevant code to respect this possible race may lead
to IOMMU mappings of, in particular, page tables, allowing the guest
to alter such page tables without Xen auditing the changes.

IMPACT
======

Malicious PV guests can escalate their privilege to that of the
hypervisor.

______________________________

Xen Security Advisory XSA-287
                              version 2

         x86: steal_page violates page_struct access discipline

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

Metadata updated to remove dependency on XSA-283.

Public release.

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

Xen's reference counting rules were designed to allow pages to change
owner and state without requiring a global lock.  Each page has a page
structure, and a very specific set of access disciplines must be
observed to ensure that pages are freed properly, and that no writable
mappings exist for PV pagetable pages.

Unfortunately, when the XENMEM_exchange hypercall was introduced,
these access disciplines were violated, opening up several potential
race conditions.

IMPACT
======

A single PV guest can leak arbitrary amounts of memory, leading to a
denial of service.

A cooperating pair of PV and HVM/PVH guests can get a writable
pagetable entry, leading to information disclosure or privilege
escalation.

Privilege escalation attacks using only a single PV guest or a pair of
PV guests have not been ruled out.

Note that both of these attacks require very precise timing, which may
be difficult to exploit in practice.

______________________________

Xen Security Advisory XSA-288
                              version 2

                 x86: Inconsistent PV IOMMU discipline

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

Metadata updated to remove dependency on XSA-283.

4.7 backport updated to fix a debug build failure.

Public release.

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

In order for a PV domain to set up DMA from a passed-through device to
one of its pages, the page must be mapped in the IOMMU.  On the other
hand, before a PV page may be used as a "special" page type (such as a
pagetable or descriptor table), it _must not_ be writable in the IOMMU
(otherwise a malicious guest could DMA arbitrary page tables into the
memory, bypassing Xen's safety checks); and Xen's current rule is to
have such pages not in the IOMMU at all.

Until now, in order to accomplish this, the code has borrowed HVM
domain's "physmap" concept: When a page is assigned to a guest,
guess_physmap_add_entry() is called, which for PV guests, will create
a writable IOMMU mapping; and when a page is removed,
guest_physmap_remove_entry() is called, which will remove the mapping.

Additionally, when a page gains the PGT_writable page type, the page
will be added into the IOMMU; and when the page changes away from a
PGT_writable type, the page will be removed from the IOMMU.

Unfortunately, borrowing the "physmap" concept from HVM domains is
problematic.  HVM domains have a lock on their p2m tables, ensuring
synchronization between modifications to the p2m; and all hypercall
parameters must first be translated through the p2m before being used.
Trying to mix this locked-and-gated approach with PV's lock-free
approach leads to several races and inconsistencies.

IMPACT
======

An untrusted PV domain with access to a physical device can DMA into
its own pagetables, leading to privilege escalation.
______________________________

Xen Security Advisory XSA-289
                              version 3

               Cache-load gadgets exploitable with L1TF

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

Rewrite text for technical accuracy.  Previous references to Spectre v1
gadgets were not correct.  In particular, the Xen Security Team is still
unaware of any Spectre v1 gadgets in Xen.

State that x86 PV guests cannot exploit the vulnerability.

Mention use of xen-hptool, and xl global affinity masks, as possible
mitigation approaches.

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

Previously reported vulnerabilities CVE-2017-5753 / XSA-254 (Spectre V1)
and CVE-2018-3646 / XSA-273 (L1TF) can, when combined, be leveraged to
more easily gather leaked information.

A Spectre v1 gadget is a speculation sequence which starts with a
conditional branch, contains a memory load who's address is
attacker-influenced, and a second action dependent on the content of the
first memory load, which opens a sidechannel with the attacker.

These gadgets are rare in code, and so far, none have been discovered in
Xen.  However, the first half of this gadget (i.e. to the first memory
load) is a very common sequence to find in compiled C, and forms an
arbitrary cache-load gadget.

An attacker can combine cache-load gadgets like this to bring data into
the cache on on hyperthread of a given CPU core, while L1TF is used on
another hyperthread to read the cached data.

A number of specific exploitable gadgets have been identified.

There are no new vulnerabilities.  There is only new information about
existing vulnerabilities: specifically, confirmation that existing,
previously disclosed, vulnerabilities, can be exploited in specific
ways.  (Previously, it was merely expected, and stated in XSA-254 and
XSA-273, that such the vulnerabilities would be exploitable.)

IMPACT
======

An attacker can potentially read arbitrary host RAM.  This includes data
belonging to Xen, data belonging to other guests, and data belonging to
different security contexts within the same guest.

An attacker could be a guest kernel (which can manipulate the pagetables
directly), or could be guest userspace either directly (e.g. with
mprotect() or similar system call) or indirectly (by gaming the guest
kernel's paging subsystem).

See XSA-254 and XSA-273 for more general information about the
underlying vulnerabilities.

______________________________

 Xen Security Advisory XSA-290
                              version 2

         missing preemption in x86 PV page table unvalidation

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

Metadata updated to remove dependency on XSA-283.

Public release.

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

XSA-273 changes required, among other things, making any PTE updates
restartable.  The changes making PTE updates restartable assumed that L2
pagetables would always be promoted preemptibly; but this turns out not
to be the case when using the 'linear pagetable' feature; the result was
that interrupted operations are not handled properly in certain cases.

Furthermore, previous security work making pagetable update preemptible
failed to account for 'linear pagetables' at L3 and L4 levels, making it
possible for operations to run for longer than acceptable times.

IMPACT
======

Malicious or buggy x86 PV guest kernels can mount a Denial of Service
(DoS) attack affecting the whole system.


______________________________

Xen Security Advisory XSA-291
                              version 2

  x86/PV: page type reference counting issue with failed IOMMU update

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

Metadata updated to remove dependency on XSA-283.

Public release.

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

When an x86 PV domain has a passed-through PCI device assigned, IOMMU
mappings may need to be updated when the type of a particular page
changes.  Such an IOMMU operation may fail.  In the event of failure,
while at present the affected guest would be forcibly crashed, the
already recorded additional type reference was not dropped again.  This
causes a bug check to trigger while cleaning up after the crashed
guest.

IMPACT
======

Malicious or buggy x86 PV guest kernels can mount a Denial of Service
(DoS) attack affecting the whole system.

______________________________

Xen Security Advisory XSA-292
                              version 2

            x86: insufficient TLB flushing when using PCID

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

Metadata updated to remove dependency on XSA-283.

Public release.

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

Use of Process Context Identifiers (PCID) was introduced into Xen in
order to improve performance after XSA-254 (and in particular its
Meltdown sub-issue).  This enablement implied changes to the TLB
flushing logic.  The particular case of context switch to a vCPU of a
PCID-enabled guest left open a time window between the full TLB flush,
and the actual address space switch, during which additional TLB
entries (from the address space about to be switched away from) can be
accumulated, which will not subsequently be purged.

IMPACT
======

Malicious PV guests may be able to cause a host crash (Denial of
Service) or to gain access to data pertaining to other guests.
Privilege escalation opportunities cannot be ruled out.

Additionally, vulnerable configurations are likely to be unstable even
in the absence of an attack.

______________________________

Xen Security Advisory XSA-293
                              version 3

                x86: PV kernel context switch corruption

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

Public release.

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

On hardware supporting the fsgsbase feature, 64bit PV guests can set and
clear the applicable control bit in its virtualised %cr4, but the
feature remains fully active in hardware.  Therefore, the associated
instructions are actually usable.

Linux, which does not currently support this feature, has various
optimisations in its context switch path which justifiably assume that
userspace can't actually make changes without a system call.

Xen's behaviour of having this feature active behind the guest kernel's
back undermines the correctness of any context switch logic which
depends on the feature being disabled.

Userspace can therefore corrupt fsbase or gsbase (commonly used for
Thread Local Storage) in the next thread to be scheduled on the
current vcpu.

IMPACT
======

A malicious unprivileged guest userspace process can escalate its
privilege to that of other userspace processes in the same guest, and
potentially thereby to that of the guest operating system.

Additionally, some guest software which attempts to use this CPU
feature may trigger the bug accidentally, leading to crashes or
corruption of other processes in the same guest.

______________________________

 Xen Security Advisory XSA-294
                              version 2

         x86 shadow: Insufficient TLB flushing when using PCID

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

Public release.

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

Use of Process Context Identifiers (PCID) was introduced into Xen in
order to improve performance after XSA-254 (and in particular its
Meltdown sub-issue).  This enablement implied changes to the TLB
flushing logic.  One aspect which was overlooked is the safety of
switching between shadow pagetables, which previously relied on the
unconditional flushing of a write to CR3.

With PCID enabled, a switch of shadow pagetable for a 64bit PV guest
fails to invalidate the linear mappings of the previous shadow
pagetable.  As a result, subsequent accesses to the shadow pagetables
may be deemed to be safe by the shadow logic (based on the old shadow
pagetable) but fault when made in practice.

IMPACT
======

Malicious 64bit PV guests may be able to cause a host crash (Denial of
Service).

Additionally, vulnerable configurations are unstable even in the absence
of an attack.

[Comment 6 Thomas Deutschmann (RETIRED) 2019-03-09 18:24:51 UTC]

x86 cannot stabilize due to bug 679860.

[Comment 7 Mikle Kolyada (RETIRED) 2019-03-17 23:03:23 UTC]

amd64 stable

[Comment 8 Yury German 2019-03-24 21:31:16 UTC]

Ping x86 stabilization.

[Comment 9 Thomas Deutschmann (RETIRED) 2019-03-27 23:47:16 UTC]

x86 stable

[Comment 10 Aaron Bauman (RETIRED) 2019-03-28 00:00:21 UTC]

@maintainer, please drop vulnerable.

[Comment 11 Yury German 2019-03-28 03:47:52 UTC]

Maintainer(s), please drop the vulnerable version(s).

[Comment 12 Tomáš Mózes 2019-04-03 17:17:24 UTC]

Vulnerable versions dropped.

[Comment 13 GLSAMaker/CVETool Bot 2019-04-04 05:00:56 UTC]

This issue was resolved and addressed in
 GLSA 201904-09 at https://security.gentoo.org/glsa/201904-09
by GLSA coordinator Aaron Bauman (b-man).

[Comment 14 Tomáš Mózes 2019-04-04 13:56:35 UTC]

GLSA https://security.gentoo.org/glsa/201904-09 mentions non-existing versions, the correct ones are:
app-emulation/xen-4.10.3-r1
app-emulation/xen-pvgrub-4.10.3

[Comment 15 Aaron Bauman (RETIRED) 2019-04-04 18:35:13 UTC]

(In reply to Tomáš Mózes from comment #14)
> GLSA https://security.gentoo.org/glsa/201904-09 mentions non-existing
> versions, the correct ones are:
> app-emulation/xen-4.10.3-r1
> app-emulation/xen-pvgrub-4.10.3

fixed.

[Comment 16 Tomáš Mózes 2019-04-05 05:09:26 UTC]

(In reply to Aaron Bauman from comment #15)
> (In reply to Tomáš Mózes from comment #14)
> > GLSA https://security.gentoo.org/glsa/201904-09 mentions non-existing
> > versions, the correct ones are:
> > app-emulation/xen-4.10.3-r1
> > app-emulation/xen-pvgrub-4.10.3
> 
> fixed.

Thank you