Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 512294 - app-emulation/xen: Vulnerabilities in HVM MSI injection (XSA-96) (CVE-2014-{3967,3968})
Summary: app-emulation/xen: Vulnerabilities in HVM MSI injection (XSA-96) (CVE-2014-{3...
Status: RESOLVED FIXED
Alias: None
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: CVE-2013-3495
  Show dependency tree
 
Reported: 2014-06-03 14:22 UTC by Agostino Sarubbo
Modified: 2015-04-11 20:37 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-06-03 14:22:34 UTC
From ${URL} :

                    Xen Security Advisory XSA-96
                            version 2

                Vulnerabilities in HVM MSI injection

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

Public release.

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

The implementation of the HVM control operation HVMOP_inject_msi, while
checking whether a particular IRQ was already set up in the necessary
way, fails to properly check all respective conditions. In particular
it doesn't check the returned pointer for being non-NULL before de-
referencing it.

Furthermore that same code also handles certain errors by logging
messages, without (under default settings) at least making these
messages subject to rate limiting.

IMPACT
======

The NULL pointer de-reference would lead to a host crash, and hence a
denial of service would result. Since host and guest page tables are
fully separated for HVM guests, the guest would not be able to leverage
the vulnerability for other kinds of attacks (privilege escalation or
information leak).

The spamming of the hypervisor log could similarly lead to a denial of
service.

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.2 onwards are vulnerable.

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 exercise 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 attached patch resolves this issue.

xsa96.patch        xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x



@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 archtester gentoo-dev 2014-06-14 07:23:33 UTC
fixed as part of bug 512572
Comment 2 Yury German Gentoo Infrastructure gentoo-dev 2014-06-16 03:53:31 UTC
Setting this bug as Primary not 512572 since that one is ARM only and does not need to be stabilized.

Please advise when ready for stabilization.
Comment 3 GLSAMaker/CVETool Bot gentoo-dev 2015-01-04 21:37:55 UTC
CVE-2014-3968 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3968):
  The HVMOP_inject_msi function in Xen 4.2.x, 4.3.x, and 4.4.x allows local
  guest HVM administrators to cause a denial of service (host crash) via a
  large number of crafted requests, which trigger an error messages to be
  logged.

CVE-2014-3967 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3967):
  The HVMOP_inject_msi function in Xen 4.2.x, 4.3.x, and 4.4.x does not
  properly check the return value from the IRQ setup check, which allows local
  HVM guest administrators to cause a denial of service (NULL pointer
  dereference and crash) via unspecified vectors.
Comment 4 Yury German Gentoo Infrastructure gentoo-dev 2015-04-05 03:49:39 UTC
Maintainer(s), Thank you for you for cleanup.

Added to an existing GLSA Request.
Comment 5 GLSAMaker/CVETool Bot gentoo-dev 2015-04-11 20:37:23 UTC
This issue was resolved and addressed in
 GLSA 201504-04 at https://security.gentoo.org/glsa/201504-04
by GLSA coordinator Yury German (BlueKnight).