Bug 530182 (CVE-2014-8594) – <app-emulation/xen-{4.2.5-r2,4.3.3-r2}: multiple vulnerabilities (CVE-2014-{8594,8595,9030)}

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Agostino Sarubbo 2014-11-23 15:34:14 UTC]

From http://www.openwall.com/lists/oss-security/2014/11/18/9:

             Xen Security Advisory CVE-2014-8594 / XSA-109
                               version 3

        Insufficient restrictions on certain MMU update hypercalls

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

Public release.

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

MMU update operations targeting page tables are intended to be used on
PV guests only. The lack of a respective check made it possible for
such operations to access certain function pointers which remain NULL
when the target guest is using Hardware Assisted Paging (HAP).

IMPACT
======

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only PV domains with privilege over other guests can exploit this
vulnerability; and only when those other guests are HVM using HAP, or
PVH.  The vulnerability is therefore exposed to PV domains providing
hardware emulation services to HVM guests.

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

Xen 4.0 and onward are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

The vulnerability is only exposed to PV service domains for HVM or
PVH 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 or PVH
service domain software (probably, the device model domain image in the
HVM case) is not always supplied by the host administrator, a malicious
service domain administrator can exercise this vulnerability.

MITIGATION
==========

Running only PV guests or HVM guests with shadow paging enabled will
avoid this issue.

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



From http://www.openwall.com/lists/oss-security/2014/11/18/8:

            Xen Security Advisory CVE-2014-8595 / XSA-110
                              version 3

    Missing privilege level checks in x86 emulation of far branches

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

Public release.

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

The emulation of far branch instructions (CALL, JMP, and RETF in Intel
assembly syntax, LCALL, LJMP, and LRET in AT&T assembly syntax)
incompletely performs privilege checks.

However these instructions are not usually handled by the emulator.
Exceptions to this are
- - when a memory operand lives in (emulated or passed through) memory
  mapped IO space,
- - in the case of guests running in 32-bit PAE mode, when such an
  instruction is (in execution flow) within four instructions of one
  doing a page table update,
- - when an Invalid Opcode exception gets raised by a guest instruction,
  and the guest then (likely maliciously) alters the instruction to
  become one of the affected ones,
- - when the guest is in real mode (in which case there are no privilege
  checks anyway).

IMPACT
======

Malicious HVM guest user mode code may be able to elevate its
privileges to guest supervisor mode, or to crash the guest.

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

Xen 3.2.1 and onward are vulnerable on x86 systems.

ARM systems are not vulnerable.

Only user processes in x86 HVM guests can take advantage of this
vulnerability.

MITIGATION
==========

Running only PV guests will avoid this issue.

There is no mitigation available for HVM guests.



From http://www.openwall.com/lists/oss-security/2014/11/20/27:

                    Xen Security Advisory XSA-113

  Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling

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

An error handling path in the processing of MMU_MACHPHYS_UPDATE failed
to drop a page reference which was acquired in an earlier processing
step.

IMPACT
======

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only domains controlling HVM guests can exploit this vulnerability.
(This includes domains providing hardware emulation services to HVM
guests.)

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

Xen versions from at least 3.2.x onwards are vulnerable on x86 systems.
Older versions have not been inspected.  ARM systems are not vulnerable.

This vulnerability is only applicable to Xen systems using stub domains
or other forms of disaggregation of control domains for HVM guests.

MITIGATION
==========

Running only PV guests will avoid this issue.

(The security of a Xen system using stub domains 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.)



@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 2014-11-26 03:31:07 UTC]

+*xen-4.4.1-r3 (26 Nov 2014)
+*xen-4.3.3-r2 (26 Nov 2014)
+*xen-4.2.5-r2 (26 Nov 2014)
+
+  26 Nov 2014; Yixun Lan <[e-mail]> +xen-4.2.5-r2.ebuild,
+  +xen-4.3.3-r2.ebuild, +xen-4.4.1-r3.ebuild:
+  security version bump, bug 530182

Arches, please test and mark stable:
=app-emulation/xen-4.2.5-r2
Target keywords Both : "amd64 x86"

=app-emulation/xen-4.3.3-r2
Target keywords Only: "amd64"

[Comment 2 Agostino Sarubbo 2014-11-26 13:53:20 UTC]

amd64 stable

[Comment 3 GLSAMaker/CVETool Bot 2014-11-27 06:17:02 UTC]

CVE-2014-9030 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-9030):
  The do_mmu_update function in arch/x86/mm.c in Xen 3.2.x through 4.4.x does
  not properly manage page references, which allows remote domains to cause a
  denial of service by leveraging control over an HVM guest and a crafted
  MMU_MACHPHYS_UPDATE.

CVE-2014-8595 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-8595):
  arch/x86/x86_emulate/x86_emulate.c in Xen 3.2.1 through 4.4.x does not
  properly check privileges, which allows local HVM guest users to gain
  privileges or cause a denial of service (crash) via a crafted (1) CALL, (2)
  JMP, (3) RETF, (4) LCALL, (5) LJMP, or (6) LRET far branch instruction.

CVE-2014-8594 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-8594):
  The do_mmu_update function in arch/x86/mm.c in Xen 4.x through 4.4.x does
  not properly restrict updates to only PV page tables, which allows remote PV
  guests to cause a denial of service (NULL pointer derference) by leveraging
  hardware emulation services for HVM guests using Hardware Assisted Paging
  (HAP).

[Comment 4 Agostino Sarubbo 2014-12-26 10:15:53 UTC]

x86 stable.

Maintainer(s), please cleanup.
Security, please vote.

[Comment 5 Yury German 2014-12-29 00:31:12 UTC]

Cleaned up as part of a different bug:
21 Dec 2014; Yixun Lan <[e-mail]> -xen-4.2.5-r1.ebuild,
6	  -xen-4.2.5-r2.ebuild, -xen-4.3.3-r2.ebuild, -xen-4.4.1-r3.ebuild:
7	  clean old, bug 532030

Arches and Maintainer(s), Thank you for your work.

GLSA Vote: Yes

[Comment 6 Agostino Sarubbo 2015-01-21 10:11:05 UTC]

http://www.openwall.com/lists/oss-security/2015/01/20/10

UPDATES IN VERSION 4
====================

Impact on applicable affected systems is a privilege escalation, not
just a denial of service.  (Because a PV guest can map something at 0,
and its address space is visible while Xen is running, so a NULL
pointer dereference can be made to do more than just crash.)

Also add a caveat to the comments in Mitigation about restricted
service domain images in radically disaggregated systems.


Switch to B1

Security, please add it to the existing request, or file a new one.

[Comment 7 Yury German 2015-02-01 02:17:42 UTC]

New GLSA Request filed.

[Comment 8 GLSAMaker/CVETool Bot 2015-04-11 20:37:42 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).