Xen Security Advisory 214 - grant transfer allows PV guest to elevate privileges

Xen Security Advisory 214 - grant transfer allows PV guest to elevate privileges

[Xen.org security team]

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

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

                    Xen Security Advisory XSA-214
                              version 2

         grant transfer allows PV guest to elevate privileges

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

Public release.

Added email header syntax to patches, for e.g. git-am.

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.

CREDITS
=======

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

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*
1c038c3927d08e6abdf3ce320bb8b0b68a106e6ac86b4e8194035dc5e4726d64  xsa214.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

iQEcBAEBCAAGBQJZCGsBAAoJEIP+FMlX6CvZtvQH/i2VsJ5AIku19/0AfiuVA6WN
WOu6TBGsaLTAXZHM/CPAOYuPHJ2dQlXRB+avo/Wu8MpuYIVrSarlfED8puDgwO2t
vZp8k5KMV4hWY7EYWYuhMvJVgNK2kjRIsM8g4T56Tc8waQdFBVH1ODEFLOdTT2jf
gVuEjV9vpdzW994N38QRLYuaaQwLGPf9yAx1pgcMr1K3qzcOOBiNqCtb1amYo84i
e/xXSV7Y87/mZxsq23ZhrRgTogiIeZO3LnLnYyYqplTGNKZli6RyvlpLzADQNdae
lpvLGHLRuIiLEFBqhINVDshRHu2cp346dOTTS8bjEfFD/d5NBUYjddP2QogqCqo=
=g4Jg
-----END PGP SIGNATURE-----

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

From: Jan Beulich <jbeulich@suse.com>
Subject: x86: discard type information when stealing pages

While a page having just a single general reference left necessarily
has a zero type reference count too, its type may still be valid (and
in validated state; at present this is only possible and relevant for
PGT_seg_desc_page, as page tables have their type forcibly zapped when
their type reference count drops to zero, and
PGT_{writable,shared}_page pages don't require any validation). In
such a case when the page is being re-used with the same type again,
validation is being skipped. As validation criteria differ between
32- and 64-bit guests, pages to be transferred between guests need to
have their validation indicator zapped (and with it we zap all other
type information at once).

This is XSA-214.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4466,6 +4466,17 @@ int steal_page(
         y = cmpxchg(&page->count_info, x, x & ~PGC_count_mask);
     } while ( y != x );
 
+    /*
+     * With the sole reference dropped temporarily, no-one can update type
+     * information. Type count also needs to be zero in this case, but e.g.
+     * PGT_seg_desc_page may still have PGT_validated set, which we need to
+     * clear before transferring ownership (as validation criteria vary
+     * depending on domain type).
+     */
+    BUG_ON(page->u.inuse.type_info & (PGT_count_mask | PGT_locked |
+                                      PGT_pinned));
+    page->u.inuse.type_info = 0;
+
     /* Swizzle the owner then reinstate the PGC_allocated reference. */
     page_set_owner(page, NULL);
     y = page->count_info;

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

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