==================================================================== CERT-Renater Note d'Information No. 2017/VULN131 _____________________________________________________________________ DATE : 03/05/2017 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-213.html https://xenbits.xen.org/xsa/advisory-214.html https://xenbits.xen.org/xsa/advisory-215.html ____________________________________________________________________ Xen Security Advisory XSA-213 version 2 x86: 64bit PV guest breakout via pagetable use-after-mode-change UPDATES IN VERSION 2 ==================== Public release. Added email header syntax to patches, for e.g. git-am. ISSUE DESCRIPTION ================= 64-bit PV guests typically use separate (root) page tables for their kernel and user modes. Hypercalls are accessible to guest kernel context only, which certain hypercall handlers make assumptions on. The IRET hypercall (replacing the identically name CPU instruction) is used by guest kernels to transfer control from kernel mode to user mode. If such an IRET hypercall is placed in the middle of a multicall batch, subsequent operations invoked by the same multicall batch may wrongly assume the guest to still be in kernel mode. If one or more of these subsequent operations involve operations on page tables, they may be using the wrong root page table, confusing internal accounting. As a result the guest may gain writable access to some of its page tables. IMPACT ====== A malicious or buggy 64-bit PV guest may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS ================== All 64-bit Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. The vulnerability is only exposed to 64-bit PV guests. HVM guests and 32-bit PV guests can't exploit the vulnerability. MITIGATION ========== Running only HVM or 32-bit PV guests will avoid the vulnerability. 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 Jann Horn of Google Project Zero. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa213.patch xen-unstable xsa213-4.8.patch Xen 4.8.x xsa213-4.7.patch Xen 4.7.x xsa213-4.6.patch Xen 4.6.x xsa213-4.5.patch Xen 4.5.x $ sha256sum xsa213* cddea5eac2ad1f5a68b561da4e98afce891189a2fdedf93087a03889e9df6e99 xsa213.patch fce9bbc9fc30769dfbab4d1830d87d220000b2742e5e70aac22f3e9d013b7614 xsa213-4.5.patch dce026ed1a02db1cf22de89120e7129839f656d041379c450e7403ae909e7b99 xsa213-4.6.patch d8202db5981e2f13d9942332cd3fefded98a5cbc302caee431c7a15051887e7f xsa213-4.7.patch 20c12810ac73809ba74cfde811d420b1b544a07f759c393380afde1a09eb5274 xsa213-4.8.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 XSA-214 version 2 grant transfer allows PV guest to elevate privileges UPDATES IN VERSION 2 ==================== Public release. Added email header syntax to patches, for e.g. git-am. ISSUE DESCRIPTION ================= The GNTTABOP_transfer operation allows one guest to transfer a page to another guest. The internal processing of this, however, does not include zapping the previous type of the page being transferred. This makes it possible for a PV guest to transfer a page previously used as part of a segment descriptor table to another guest while retaining the "contains segment descriptors" property. If the destination guest is a PV one of different bitness, it may gain access to segment descriptors it is not normally allowed to have, like 64-bit code segments in a 32-bit PV guest. If the destination guest is a HVM one, that guest may freely alter the page contents and then hand the page back to the same or another PV guest. In either case, if the destination PV guest then inserts that page into one of its own descriptor tables, the page still having the designated type results in validation of its contents being skipped. IMPACT ====== A malicious pair of guests may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS ================== All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. MITIGATION ========== Running only one out of the three relevant classes of guest (namely: 32-bit PV; 64-bit PV; HVM) on any given host will avoid the vulnerability. (Note that this must also include any nonprivileged service domains such as stub device model domains.) The vulnerability can also be avoided if all guest kernels are 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 Jann Horn of Google Project Zero. RESOLUTION ========== Applying the attached patch resolves this issue. xsa124.patch xen-unstable, Xen 4.8.x, 4.7.x, 4.6.x, 4.5.x $ sha256sum xsa214* 1c038c3927d08e6abdf3ce320bb8b0b68a106e6ac86b4e8194035dc5e4726d64 xsa214.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 XSA-215 version 2 possible memory corruption via failsafe callback UPDATES IN VERSION 2 ==================== Public release. Added email header syntax to patches, for e.g. git-am. ISSUE DESCRIPTION ================= Under certain special conditions Xen reports an exception resulting from returning to guest mode not via ordinary exception entry points, but via a so call failsafe callback. This callback, unlike exception handlers, takes 4 extra arguments on the stack (the saved data selectors DS, ES, FS, and GS). Prior to placing exception or failsafe callback frames on the guest kernel stack, Xen checks the linear address range to not overlap with hypervisor space. The range spanned by that check was mistakenly not covering these extra 4 slots. IMPACT ====== A malicious or buggy 64-bit PV guest may be able to modify part of a physical memory page not belonging to it, potentially allowing for all of privilege escalation, host or other guest crashes, and information leaks. VULNERABLE SYSTEMS ================== 64-bit Xen versions 4.6 and earlier are vulnerable. Xen versions 4.7 and later are not vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. Only x86 systems with physical memory extending to a configuration dependent boundary (5Tb or 3.5Tb) may be affected. Whether they are actually affected depends on actual physical memory layout. The vulnerability is only exposed to 64-bit PV guests. HVM guests and 32-bit PV guests can't exploit the vulnerability. MITIGATION ========== Running only HVM or 32-bit PV guests will avoid the vulnerability. 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 Jann Horn of Google Project Zero. RESOLUTION ========== Applying the attached patch resolves this issue. xsa215.patch Xen 4.6.x, Xen 4.5.x $ sha256sum xsa215* 5be4ff661dd22890b0120f86beee3ec809e2a29f833db8c48bd70ce98e9691ee xsa215.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 + ==========================================================