Date: Tue, 29 Apr 2014 12:22:09 +0000 From: Xen.org security team <security@....org> To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org, xen-users@...ts.xen.org, oss-security@...ts.openwall.com CC: Xen.org security team <security@....org> Subject: Xen Security Advisory 92 - HVMOP_set_mem_type allows invalid P2M entries to be created -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory XSA-92 version 2 HVMOP_set_mem_type allows invalid P2M entries to be created UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The implementation in Xen of the HVMOP_set_mem_type HVM control operations attempts to exclude transitioning a page from an inappropriate memory type. However, only an inadequate subset of memory types is excluded. There are certain other types that don't correspond to a particular valid page, whose page table translation can be inappropriately changed (by HVMOP_set_mem_type) from not-present (due to the lack of valid memory page) to present. If this occurs, an invalid translation will be established. 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 crash leading to a Denial of Service. Arbitrary code execution, and therefore privilege escalation, cannot be entirely excluded: On a system with a RAM page present immediately below the 52-bit address boundary, this would be possible. However, we are not aware of any systems with such a memory layout. VULNERABLE SYSTEMS ================== All Xen versions from 4.1 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 appropriate attached patch resolves this issue. xsa92.patch xen-unstable, Xen 4.4.x, Xen 4.3.x xsa92-4.2.patch Xen 4.2.x xsa92-4.1.patch Xen 4.1.x $ sha256sum xsa92*.patch 184dcb88dfb4540fca33016ffcfe0f4f557449ab5b4ec6a4bf486c75926d23f3 xsa92.patch 76905398958dfcec98fb5bde2a68c0e86a3ccc9f442a8a658e972937fd75534a xsa92-4.1.patch bca98827834f807c787fceb6c719d9d4fe3c40786cb087156829e5e6fb5700d6 xsa92-4.2.patch $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTX2euAAoJEIP+FMlX6CvZx3EIAIzdz8WxP0NPPDbY9QaM6nz7 H0kq8MxB1wcC2mTREPa+B5/vzC52VEC5JLEfWNs/6sMc6nBmbe+F+EqiIpgbuuTA kq9L0ycPjBsEqKKwZDuqDzHVlnpjEX7oNb7x32eafrR3jWp1CIKTt4dmQqQn/PNR 3CVg7nc+lMmusXElJeqHA8a+pqQgBXFAKVbQiBqRIDwPRdBCbJmwbkhsbfa4zF3T Fyzm1am52T3nhml0opNb32rkK3VblJbLGJ6jkyWweTYqiVLZc9pOF58W7t6L3QS2 BmnhRdwy9b+cHn5eLI3529KBmkrWhZ26Fn8mPwgXWm7p08ybfGEFMZKp2G5rYE8= =r7s4 -----END PGP SIGNATURE----- Download attachment "xsa92.patch" of type "application/octet-stream" (1312 bytes) Download attachment "xsa92-4.1.patch" of type "application/octet-stream" (2459 bytes) Download attachment "xsa92-4.2.patch" of type "application/octet-stream" (1313 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ