Xen Security Advisory 217 (CVE-2017-10912) - page transfer may allow PV guest to elevate privilege

Xen Security Advisory 217 (CVE-2017-10912) - page transfer may allow PV guest to elevate privilege

[Xen.org security team]

[-- Attachment #1: Type: text/plain, Size: 3869 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2017-10912 / XSA-217
                              version 3

         page transfer may allow PV guest to elevate privilege

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

CVE assigned.

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

Domains controlling other domains are permitted to map pages owned by
the domain being controlled.  If the controlling domain unmaps such a
page without flushing the TLB, and if soon after the domain being
controlled transfers this page to another PV domain (via
GNTTABOP_transfer or, indirectly, XENMEM_exchange), and that third
domain uses the page as a page table, the controlling domain will have
write access to a live page table until the applicable TLB entry is
flushed or evicted.  Note that the domain being controlled is
necessarily HVM, while the controlling domain is PV.

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.

Only systems where an attacker can control both a PV and an HVM guest
are vulnerable.  This must be presumed to include systems containing
HVM domains with service domains such as stub domain device models.

Systems containing only PV guests are not vulnerable.

Systems containing only HVM domains serviced by dom0 device model
processes are not vulnerable.  Note that with libxl, xl, and libvirt,
HVM domains use dom0 device model processes by default.

MITIGATION
==========

There is no mitigation for this vulnerability.

Switching from stub device models to dom0 process device models is not
recommended as a mitigation, as in practice the vulnerability is
likely to be hard to exploit through this route; whereas dom0 process
device models may have unknown vulnerabilities.

CREDITS
=======

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

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

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

$ sha256sum xsa217*
3e896412389d8e59e417ea7bb3d5b47a20de27b8eae0420c98071ce4b17d219c  xsa217.patch
4e555cf47faf5e8d2bba4ff8a31fbe72fb11a6c0e3b286f23b26e684a1809705  xsa217-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

iQEcBAEBCAAGBQJZX5IlAAoJEIP+FMlX6CvZCC8IAJ8VgkRigZpOyxl1CHP+pSGu
TZzWOS0xCMsuIkbPaGgfbgykNh7/7byWWPBZwoUSKh1gnWXIohFtRr3JvPKlsb8X
5nthArzR1biR4c9kXL7TYiLhxoInHYT3tE7tnAj6c68qxWLrkQuTW3C3kJnlVf+p
XXIju4ccV33X0hT1nqOr5P9FqhmDKgml4qeaUnEabFjXgM16/JaHM8f2k2U/FYJP
mfrh+5EeAMg3i1OdtLklMyEUXlA1IE2m7BsfnA3eMQ9xc50mjEQ/NZYhe3knv7IX
KfvRMMZgjTvEO/6GU7Qt5qlBRLj1e/jpxaviHsdZaLPoHz4Cq4WncdfyqfAJ1Dk=
=WueX
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa217.patch --]
[-- Type: application/octet-stream, Size: 1384 bytes --]

From: Jan Beulich <jbeulich@suse.com>
Subject: x86/mm: disallow page stealing from HVM domains

The operation's success can't be controlled by the guest, as the device
model may have an active mapping of the page. If we nevertheless
permitted this operation, we'd have to add further TLB flushing to
prevent scenarios like

"Domains A (HVM), B (PV), C (PV); B->target==A
 Steps:
 1. B maps page X from A as writable
 2. B unmaps page X without a TLB flush
 3. A sends page X to C via GNTTABOP_transfer
 4. C maps page X as pagetable (potentially causing a TLB flush in C,
 but not in B)

 At this point, X would be mapped as a pagetable in C while being
 writable through a stale TLB entry in B."

A similar scenario could be constructed for A using XENMEM_exchange and
some arbitrary PV domain C then having this page allocated.

This is XSA-217.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4449,6 +4449,9 @@ int steal_page(
     bool_t drop_dom_ref = 0;
     const struct domain *owner = dom_xen;
 
+    if ( paging_mode_external(d) )
+        return -1;
+
     spin_lock(&d->page_alloc_lock);
 
     if ( is_xen_heap_page(page) || ((owner = page_get_owner(page)) != d) )

[-- Attachment #3: xsa217-4.5.patch --]
[-- Type: application/octet-stream, Size: 1356 bytes --]

From: Jan Beulich <jbeulich@suse.com>
Subject: x86/mm: disallow page stealing from HVM domains

The operation's success can't be controlled by the guest, as the device
model may have an active mapping of the page. If we nevertheless
permitted this operation, we'd have to add further TLB flushing to
prevent scenarios like

"Domains A (HVM), B (PV), C (PV); B->target==A
 Steps:
 1. B maps page X from A as writable
 2. B unmaps page X without a TLB flush
 3. A sends page X to C via GNTTABOP_transfer
 4. C maps page X as pagetable (potentially causing a TLB flush in C,
 but not in B)

 At this point, X would be mapped as a pagetable in C while being
 writable through a stale TLB entry in B."

A similar scenario could be constructed for A using XENMEM_exchange and
some arbitrary PV domain C then having this page allocated.

This is XSA-217.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4217,6 +4217,9 @@ int steal_page(
     unsigned long x, y;
     bool_t drop_dom_ref = 0;
 
+    if ( paging_mode_external(d) )
+        return -1;
+
     spin_lock(&d->page_alloc_lock);
 
     if ( is_xen_heap_page(page) || (page_get_owner(page) != d) )

[-- Attachment #4: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel