[oss-security] Xen Security Advisory 96 (CVE-2014-3967,CVE-2014-3968) - Vulnerabilities in HVM MSI injection

2014-06-19T00:00:00
ID SECURITYVULNS:DOC:30898
Type securityvulns
Reporter Securityvulns
Modified 2014-06-19T00:00:00

Description

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

  Xen Security Advisory CVE-2014-3967,CVE-2014-3968 / XSA-96
                        version 3

            Vulnerabilities in HVM MSI injection

UPDATES IN VERSION 3

CVEs assigned.

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. (CVE-2014-3967)

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

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

$ sha256sum xsa96*.patch 1b64beddf8f6e9c08af24676551c18fd778a8db65a6c24fec07cc7e95531e2af xsa96.patch $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJTj0MHAAoJEIP+FMlX6CvZY04H/1Udj8OzkKHHxaCLQWxAUo6w SCSV37MNRQcsJJly4KAUjsO+yyfNPnVQBUsVsBcSnKURElbkYf1IaBGSPWbiiTZY ubtQgT/rF8y0cShvDiCVXP7giwHN270F3YIXAvZPn/ZvM0a6Wad6VbBEgIo6vUeU vqb10LnrKy7S7h8sVaQCIuM5/6ysjtJAyDtlFyDN55J4socHD+oYTtU+HNbZZFvs UytIy56dtO5TSkazKgCZR936BWreYl4izOy1+elLM+r8k0qz8SdTdcVzVqNqYkMK QxjwiM7cy4fZxi1R+N/mwXgyr2tv2r/6AsdCX3vuZreg/Dp4Fi+7lDnj/sfBSGg= =fTzY -----END PGP SIGNATURE-----