Xen users - Jun 2012 - Xen Security Advisory 7 (CVE-2012-0217) - PV privilege escalation

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

              Xen Security Advisory CVE-2012-0217 / XSA-7
                            version 9

           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

$ sha256sum xsa7-xsa8-*patch
00853d799d24af16b17c8bbbdb5bb5144a8a7fad31467c4be3d879244774f8d2 
xsa7-xsa8-unstable-apr16.patch
71f9907a58c1a1cd601d8088faf8791923d78f77065b94dba8df2a61f512530d 
xsa7-xsa8-unstable-recent.patch
55fb925a7f4519ea31a0bc42d3ee83093bb7abd98b3a0e4f58591f1ae738840a 
xsa7-xsa8-xen-3.4.patch
6a7e39121ec1f134351fdf34f494d108500aaa4190a9f7965e81c4e96270924e 
xsa7-xsa8-xen-4.0.patch
52d8288718b4a833eb437fd18d92b7d412fbe01900dbd0b437744a1df4d459da 
xsa7-xsa8-xen-4.1.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJP1yqTAAoJEIP+FMlX6CvZntwH/jzuqabF9yGMIXQBckjZUv1E
XeY9dbz1uGoMzy0mBFufwbJQqdBt89SNYDkr2BxKxSghSvBs608KHuh8giF1hzvm
8oP2K5T3Rk/jl0gdc3VlZz15Yi9kVEDUOSu2rPQLbhmiv6ht+Y2Of2cp63RioEvq
G2QQouHDsipCUZV4Ow5xnPY/KBifh46uCCnLDjV5Q/6WScI8VOIreOADryOpn2+/
8QmyCo2Sl2F+YxlbCl7k3qyqihaSONymeVg0pkJbH5LmRdTQnJX9fMJSQvfV6Bxs
U4PD4ve0C9+/Usz4XFejlQLt/kv4ZNPD6QF2rXei3oElmYAVcHL2XdLVCNLbAeY=S6KX
-----END PGP SIGNATURE-----

Hello,

A quick question with regard to XSA-7:

On Tue, Jun 12, 2012 at 01:02:32PM +0100, Xen.org security team
wrote:
> MITIGATION
> =========> 
> This issue can be mitigated by running HVM (fully-virtualised)
> or 32 bit PV guests only.
Assuming 64-bit hypervisor and dom0, with PV guests booted using
pygrub, is there any way to restrict guests to 32-bit only?

Cheers,
Andy

On Tue, 2012-06-12 at 13:15 +0100, Andy Smith wrote:
> Hello,
> 
> A quick question with regard to XSA-7:
> 
> On Tue, Jun 12, 2012 at 01:02:32PM +0100, Xen.org security team wrote:
> > MITIGATION
> > =========> > 
> > This issue can be mitigated by running HVM (fully-virtualised)
> > or 32 bit PV guests only.
> 
> Assuming 64-bit hypervisor and dom0, with PV guests booted using
> pygrub, is there any way to restrict guests to 32-bit only?
Nothing which has been implemented but a couple of ideas which spring to
my mind, in no particular order:

      * A wrapper around pygrub to vet the kernel which it has
        extracted. I think this is a case of checking the machine type
        specified in the kernel''s ELF header (and that it really is ELF
        etc etc).
      * Patch tools/libxc/xc_dom_x86.c to remove the
        xc_dom_register_arch_hooks call for xc_dom_64.
      * Use XSM to deny XEN_DOMCTL_set_address_size (I''m not sure how
        this stuff works).

Realistically the only robust way (i.e. the one which you could be most
sure of doing it''s job properly with the least possibility of a
sneakily
constructed kernel getting around the validation routines etc.) would be
to do it in the hypervisor, at which point you might as well just apply
the fix.

Ian.