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.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.