|Public release ||2014-11-18 12:00|
|Updated ||2015-01-20 18:14|
|Title ||Insufficient restrictions on certain MMU update hypercalls|
Filesadvisory-109.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2014-8594 / XSA-109
Insufficient restrictions on certain MMU update hypercalls
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.
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).
Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service or privilege
escalation 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.
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
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
In those latter situations this issue means that the extra isolation
does not provide as good a defence 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.
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 (so long as there isn't also a vulnerability in the
This issue was discovered by Roger Pau Monné of Citrix and Jan Beulich
Applying the appropriate attached patch resolves this issue.
xsa109.patch xen-unstable, Xen 4.4.x, Xen 4.3.x
xsa109-4.2.patch Xen 4.2.x
$ sha256sum xsa109*.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
Xenproject.org Security Team