[Xen-devel] Xen Security Advisory 89 (CVE-2014-2599) - HVMOP_set_mem_access is not preemptible

[Xen.org security team <security@xxxxxxx>]

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

             Xen Security Advisory CVE-2014-2599 / XSA-89
                              version 3

              HVMOP_set_mem_access is not preemptible

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

This issue has been assigned CVE-2014-2599.

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

Processing of the HVMOP_set_mem_access HVM control operations does not
check the size of its input and can tie up a physical CPU for extended
periods of time.

IMPACT
======

In a configuration where device models run with limited privilege (for
example, stubdom device models), a guest attacker who successfully
finds and exploits an unfixed security flaw in qemu-dm could leverage
the other flaw into a Denial of Service affecting the whole host.

In the more general case, in more abstract terms: a malicious
administrator of a domain privileged with regard to an HVM guest can
cause Xen to become unresponsive leading to a Denial of Service.

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

All Xen versions from 4.1 onwards are vulnerable. In 4.2 only 64-bit
versions of the hypervisor are vulnerable (HVMOP_set_mem_access is not
available in 32-bit hypervisors).

The vulnerability is only exposed to service domains for HVM guests
which have privilege over the guest.  In a usual configuration that
means only device model emulators (qemu-dm).

In the case of HVM guests whose device model is running in an
unrestricted dom0 process, qemu-dm already has the ability to cause
problems for the whole system.  So in that case the vulnerability is
not applicable.

The situation is more subtle for an HVM guest with a stub qemu-dm.
That is, where the device model runs in a separate domain (in the case
of xl, as requested by "device_model_stubdomain_override=1" in the xl
domain configuration file).  The same applies with a qemu-dm in a dom0
process subjected to some kind kernel-based process privilege
limitation (eg the chroot technique as found in some versions of
XCP/XenServer).

In those latter situations this issue means that the extra isolation
does not provide as good a defence (against denial of service) as
intended.  That is the essence of this vulnerability.

However, the security is still better than with a qemu-dm running as
an unrestricted dom0 process.  Therefore users with these
configurations should not switch to an unrestricted dom0 qemu-dm.

Finally, in a radically disaggregated system: where the HVM service
domain software (probably, the device model domain image) is not
always supplied by the host administrator, a malicious service domain
administrator can excercise this vulnerability.

MITIGATION
==========

Running only PV guests will avoid this vulnerability.

In a radically disaggregated system, restricting HVM service domains
to software images approved by the host administrator will avoid the
vulnerability.

CREDITS
=======

This issue was discovered by Jan Beulich.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa89.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x
xsa89-4.1.patch    Xen 4.1.x

$ sha256sum xsa89*.patch
741c8fbbfa8e425d8debba17135d4c2e1e962d15717769bc93d68a65b5dc5ea6  xsa89.patch
7d965e9bf1894b7d909bfaddbc6b7bdcee0ba91b86942ce85e0ae80464f2463e  
xsa89-4.1.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJTO+8wAAoJEIP+FMlX6CvZ5esH/3T+ajm7vltauel3SR3+wQAw
nmxJR+CIaIRhIdjER/EPJ8HRqCl8DvY1yY8MM9qo70RIGu9eHSxkKbPQzNa1ye8/
sdqLT+TIVXElukse1CxSPnHkw0NYOjysdTxDs9XGFzTA2qzYj9cLu6qKbh8wKOqa
4UhqMzU5zXnRi+53Ljn3dBximU2Fch7ibN5Ea5C2e4uPJHR8aNn31lCESnsUfwbK
/ZrxoP89VRiSZq0GiGrSouF6FjU6fWyP3pTfvrFtQ0/K7a+HuA3ZgT35iGVdVW2C
dV35iNqIn+yC8vUrcEZkdfp/KapRP3WqCetoW63MT1tACToCf8ObT3RMTuAgfa0=
=vHm/
-----END PGP SIGNATURE-----

Attachment: xsa89.patch
Description: Binary data

Attachment: xsa89-4.1.patch
Description: Binary data

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