Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 505714 (CVE-2014-2599) - <app-emulation/xen-{4.2.4-r1,4.3.2-r1,4.4.0-r1}: HVMOP_set_mem_access is not preemptibleXSA-89) (CVE-2014-2599)
Summary: <app-emulation/xen-{4.2.4-r1,4.3.2-r1,4.4.0-r1}: HVMOP_set_mem_access is not ...
Status: RESOLVED FIXED
Alias: CVE-2014-2599
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: http://www.openwall.com/lists/oss-sec...
Whiteboard: B3 [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-25 13:41 UTC by Agostino Sarubbo
Modified: 2014-07-16 16:47 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2014-03-25 13:41:22 UTC
From ${URL} :

                    Xen Security Advisory XSA-89
                             version 2

              HVMOP_set_mem_access is not preemptible

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

Public release.

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
$



@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Yixun Lan gentoo-dev 2014-04-09 21:36:54 UTC
+*xen-4.4.0-r1 (09 Apr 2014)
+*xen-4.3.2-r1 (09 Apr 2014)
+*xen-4.2.4-r1 (09 Apr 2014)
+
+  09 Apr 2014; Yixun Lan <dlan@gentoo.org> +xen-4.2.4-r1.ebuild,
+  +xen-4.3.2-r1.ebuild, +xen-4.4.0-r1.ebuild:
+  bump stable patches, fix bug #505714, XSA-89
Comment 2 Yury German Gentoo Infrastructure gentoo-dev 2014-04-10 04:15:22 UTC
Maintainers, please advise when eBuild has had enough testing and is ready for stabilization.

For Versions:
+*xen-4.3.2-r1 (09 Apr 2014)
+*xen-4.2.4-r1 (09 Apr 2014)
Comment 3 GLSAMaker/CVETool Bot gentoo-dev 2014-04-28 19:25:49 UTC
CVE-2014-2599 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-2599):
  The HVMOP_set_mem_access HVM control operations in Xen 4.1.x for 32-bit and
  4.1.x through 4.4.x for 64-bit allow local guest administrators to cause a
  denial of service (CPU consumption) by leveraging access to certain service
  domains for HVM guests and a large input.
Comment 4 Yury German Gentoo Infrastructure gentoo-dev 2014-05-27 23:58:28 UTC
Is this fixed as part of Bug 500530?
Comment 5 Yixun Lan gentoo-dev 2014-05-28 02:48:46 UTC
this is already fixed, please see comment #1 of this bug.

so, all ebuilds in tree already include this fix, thanks
Comment 6 Yury German Gentoo Infrastructure gentoo-dev 2014-05-29 05:07:29 UTC
Arches and Mainter(s), Thank you for your work.

Added to an existing GLSA request.
Comment 7 GLSAMaker/CVETool Bot gentoo-dev 2014-07-16 16:47:04 UTC
This issue was resolved and addressed in
 GLSA 201407-03 at http://security.gentoo.org/glsa/glsa-201407-03.xml
by GLSA coordinator Mikle Kolyada (Zlogene).