==================================================================== CERT-Renater Note d'Information No. 2017/VULN256 _____________________________________________________________________ DATE : 14/09/2017 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-231.html https://xenbits.xen.org/xsa/advisory-232.html https://xenbits.xen.org/xsa/advisory-233.html https://xenbits.xen.org/xsa/advisory-234.html ____________________________________________________________________ Xen Security Advisory CVE-2017-14316 / XSA-231 version 3 Missing NUMA node parameter verification UPDATES IN VERSION 3 ==================== Updated metadata file Public release. ISSUE DESCRIPTION ================= The function `alloc_heap_pages` allows callers to specify the first NUMA node that should be used for allocations through the `memflags` parameter; the node is extracted using the `MEMF_get_node` macro. While the function checks to see if the special constant `NUMA_NO_NODE` is specified, it otherwise does not handle the case where `node >= MAX_NUMNODES`. This allows an out-of-bounds access to an internal array. IMPACT ====== An attacker using crafted hypercalls can execute arbitrary code within Xen. VULNERABLE SYSTEMS ================== All versions of Xen are affected. Both ARM and x86 are affected. Both systems running HVM guests and system running PV guests are affected. MITIGATION ========== No known mitigation. CREDITS ======= This issue was discovered by Matthew Daley. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa231.patch xen-unstable xsa231-4.9.patch Xen 4.9, Xen 4.8 xsa231-4.7.patch Xen 4.7, Xen 4.6 xsa231-4.5.patch Xen 4.5 $ sha256sum xsa231* 4255d2bc4ca668e7abcbf8256b0a8f21acef2a47a06d626aad6d22c685034587 xsa231.meta b72af3fb8c44925ea7973533e8a8701becfc194f3e1c97f12af0392e1edd16a3 xsa231.patch d9853b2d2649679d8810bd7e93f7b51bd9fefb3472da60ae464bde88aae3389c xsa231-4.5.patch ce29b56a0480f4835b37835b351e704d204bb0ccd22325f487127aa2776cc2cf xsa231-4.7.patch 71a53a5133c8d4e381dd0e3e54205d31dea545ab62b261084dd3aea140f88cad xsa231-4.9.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html ____________________________________________________________________ Xen Security Advisory CVE-2017-14318 / XSA-232 version 4 Missing check for grant table UPDATES IN VERSION 4 ==================== Added metadata file Public release. ISSUE DESCRIPTION ================= The function `__gnttab_cache_flush` handles GNTTABOP_cache_flush grant table operations. It checks to see if the calling domain is the owner of the page that is to be operated on. If it is not, the owner's grant table is checked to see if a grant mapping to the calling domain exists for the page in question. However, the function does not check to see if the owning domain actually has a grant table or not. Some special domains, such as `DOMID_XEN`, `DOMID_IO` and `DOMID_COW` are created without grant tables. Hence, if __gnttab_cache_flush operates on a page owned by these special domains, it will attempt to dereference a null pointer in the domain struct. IMPACT ====== The guest can get Xen to dereference a NULL pointer. For ARM guests and x86 PV guests on systems with SMAP enabled, this will cause a host crash (denial-of-service). For x86 PV guests on systems without SMAP enabled, an attacker can map a crafted grant structure at virtual address 0. This can be leveraged to increment an arbitrary virtual address, which can then probably be leveraged into a full privilege escalation. VULNERABLE SYSTEMS ================== All versions of Xen since Xen 4.5 are vulnerable. x86 HVM guests do not expose the vulnerability. ARM guests and x86 PV guests on systems with SMAP enabled are only vulnerable to a Denial-of-Service (host crash). x86 PV guests on systems without SMAP running are vulnerable to a privilege escalation. MITIGATION ========== Hardware supporting Supervisor Mode Access Prevention (Intel Broadwell, AMD Zen) can mitigate the privilege escalation to a DoS. CREDITS ======= This issue was discovered by Matthew Daley. RESOLUTION ========== Applying the attached patch resolves this issue. xsa232.patch xen-unstable, 4.9, 4.8, 4.7, 4.6, 4.5 $ sha256sum xsa232* b193a711d013fe14556610ef3e703585164fdfc437c3a32a717c419e7a5afab2 xsa232.meta 5068a78293daa58557c30c95141b775becfb650de6a5eda0d82a4a321ced551c xsa232.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html ____________________________________________________________________ Xen Security Advisory CVE-2017-14317 / XSA-233 version 3 cxenstored: Race in domain cleanup UPDATES IN VERSION 3 ==================== Added metadata file Public release. ISSUE DESCRIPTION ================= When shutting down a VM with a stubdomain, a race in cxenstored may cause a double-free. IMPACT ====== The xenstored daemon may crash, resulting in a DoS of any parts of the system relying on it (including domain creation / destruction, ballooning, device changes, etc). VULNERABLE SYSTEMS ================== All versions of Xen are vulnerable. Only systems running the C version os xenstored ("xenstored") are vulnerable; systems running the Ocaml version ("oxenstored") are not vulnerable. Only systems running devicemodel stubdomains are vulnerable. Only x86 HVM guests can use stubdomains. Therefore ARM systems, x86 systems running only PV guests, and x86 systems running HVM guests with the devicemodel not in a stubdomain (eg in dom0), are not vulnerable. MITIGATION ========== Running oxenstored will mitigate this issue. Not using stubdomains will also mitigate the issue. CREDITS ======= This issue was discovered by Eric Chanudet of AIS. RESOLUTION ========== Applying the attached patch resolves this issue. xsa233.patch xen-unstable, Xen 4.9.x Xen 4.8.x Xen 4.7.x Xen 4.6.x Xen 4.5.x $ sha256sum xsa233* 66b6f6c0837a5d12a77db7e5cbfd0514968bd47e2d192824da3bc9ddf119bfe0 xsa233.meta f721cc49ba692b2f36299b631451f51d7340b8b4732f74c98f01cb7a80d8662b xsa233.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html ____________________________________________________________________ Xen Security Advisory CVE-2017-14319 / XSA-234 version 3 insufficient grant unmapping checks for x86 PV guests UPDATES IN VERSION 3 ==================== Added metadata file Public release. ISSUE DESCRIPTION ================= When removing or replacing a grant mapping, the x86 PV specific path needs to make sure page table entries remain in sync with other accounting done. Although the identity of the page frame was validated correctly, neither the presence of the mapping nor page writability were taken into account. IMPACT ====== A malicious or buggy x86 PV guest could escalate its privileges or crash the hypervisor. VULNERABLE SYSTEMS ================== All Xen versions are affected. Only x86 PV guests can leverage the vulnerability. x86 HVM guests as well as ARM guests cannot leverage the vulnerability. MITIGATION ========== Running only HVM guests will avoid this vulnerability. However, the vulnerability is exposed to PV stub qemu serving as the device model for HVM guests. Our default assumption is that an HVM guest has compromised its PV stub qemu. By extension, it is likely that the vulnerability is exposed to HVM guests which are served by a PV stub qemu. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS ======= This issue was discovered by Andrew Cooper of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa234.patch xen-unstable xsa234-4.9.patch Xen 4.9.x xsa234-4.8.patch Xen 4.8.x, Xen 4.7.x xsa234-4.6.patch Xen 4.6.x xsa234-4.5.patch Xen 4.5.x $ sha256sum xsa234* efbcc7eac0f010281c5651d191076ac08cc7dd22a1945e88e92ba8a03ae8cc40 xsa234.meta 08ffa79e5c2a77db0b91b3bfcf9fa5c50f174fe842b7418e2e1549d47e0aec4d xsa234.patch 4b74f3c85a98bc6f40c6a448b068bf45e71f7cce887b7cb1481aca0e8746d990 xsa234-4.5.patch 3df4ce173196111c1ff849039ea4927c0b4bd632b08a501fb26f64e31b951fba xsa234-4.6.patch 169e4e0eaa6b27e58ff0f4ce50e8fcc3f81b1e0a10210decf22d1b4cac7501fb xsa234-4.8.patch 213f9d81a4ab785db67b9f579c9e88c9c8586c46b93f466a309060750df2df32 xsa234-4.9.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html ========================================================== + CERT-RENATER | tel : 01-53-94-20-44 + + 23 - 25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email: cert@support.renater.fr + ==========================================================