64-bit PV guest privilege escalation vulnerability

UPDATES IN VERSION 9
====================

Public release. Previous versions were embargoed.

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

Rafal Wojtczuk has discovered a vulnerability which can allow a 64-bit
PV guest kernel running on a 64-bit hypervisor to escalate privileges
to that of the host by arranging for a system call to return via
sysret to a non-canonical RIP. Intel CPUs deliver the resulting
exception in an undesirable processor state.

IMPACT
======

Guest administrators can gain control of the host.

Depending on the particular guest kernel it is also possible that
non-privileged guest user processes can also elevate their privileges
to that of the host.

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

All systems running 64 bit Xen hypervisor running 64 bit PV guests on
Intel CPUs are vulnerable to this issue.

Systems using AMD CPUs are not vulnerable to this privilege
escalation. AMD have issued the following statement:
AMD processors’ SYSRET behavior is such that a non-canonical
address in RCX does not generate a #GP while in CPL0. We have
verified this with our architecture team, with our design team, and
have performed tests that verified this on silicon. Therefore, this
privilege escalation exposure is not applicable to any AMD
processor.

While investigating this, it was noted that some older AMD CPUs will
lock up under similar circumstances, causing a denial of service. See
XSA-9 for details.

MITIGATION
==========

This issue can be mitigated by running HVM (fully-virtualised)
or 32 bit PV guests only.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

These patches also resolve the issue described in XSA-8 (CVE-2012-0128).

These changes have been made to the staging Xen repositories:
XSA-7: XSA-8:
xen-unstable.hg 25480:76eaf5966c05 25200:80f4113be500+25204:569d6f05e1ef
xen-4.1-testing.hg 23299:f08e61b9b33f 23300:0fec1afa4638
xen-4.0-testing.hg 21590:dd367837e089 21591:adb943a387c8
xen-3.4-testing.hg 19996:894aa06e4f79 19997:ddb7578abb89

PATCH INFORMATION
=================

The attached patches resolve both this issue and that reported in
XSA-8 (CVE-2012-0128).

xen-unstable 25204:569d6f05e1ef or later xsa7-xsa8-unstable-recent.patch
xen-unstable 25199:6092641e3644 or earlier xsa7-xsa8-unstable-apr16.patch
Xen 4.1, 4.1.x xsa7-xsa8-xen-4.1.patch
Xen 4.0, 4.0.x xsa7-xsa8-xen-4.0.patch
Xen 3.4, 3.4.x xsa7-xsa8-xen-3.4.patch

http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
http://lists.xen.org/archives/html/xen-announce/2012-06/msg00003.html
http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html

Be sure to patch up if you run Xen, and I have a feeling the fallout is far from over..

Although Solaris Zones, coupled with ZFS & Xen should be a clear winner, you’ll find out real quick that Zones do *NOT* easily allow for independant tcp/ip stacks (hope you have v3 nic drivers), the Xen networking again is a mess (v3 drivers anyone? Also those interfaces better be TCP/IP enabled on the host!) and get ready to edit the /var/lib/xend/domains directory files a LOT…. And be ready for gegrep fun. Afterall domain names like “0aa811ef-3bd0-9140-583f-d5e09f93658e” make life all the easier. I will say that Xen does use Qemu disk images so there is an easy ‘upgrade’ path to/from KVM (the linux hypervisor found in ProxmoxVE). What I don’t get is the massive disconnect between virsh & the xend process.

And if you are running Xen, the you’ll want SOME print documentation… I just wish I didn’t think it’d be that intuitive. So at least creating this:

(device
(vif
(bridge iprb0)
(uuid c0e47a99-70e5-1ebe-44a4-54895cb24a15)
(script vif-vnic)
(mac 00:16:3e:56:df:81)
(model ne2k_pci)
(backend 0)
)
)
would have been easier.
From my notes, how to tell if your nic is new enough to drive Xen/Zones:

/usr/lib/vna NIC MAC
bash-3.2# /usr/lib/vna e1000g0 0:2:a5:4c:76:74
vnic5

If you don’t get something similar, you are screwed. Additionally this guide is invaluable as it’ll be your ONLY quick guide on how to get around xen on Solaris 10.

Anyways enough Xen bashing for now, but I have to say I’m excited about going back to ProxMox VE. Just remember to leave your base OS alone…. like a mainframe.