==================================================================== CERT-Renater Note d'Information No. 2016/VULN313 _____________________________________________________________________ DATE : 12/09/2016 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== http://xenbits.xen.org/xsa/advisory-185.html http://xenbits.xen.org/xsa/advisory-186.html http://xenbits.xen.org/xsa/advisory-187.html http://xenbits.xen.org/xsa/advisory-188.html ____________________________________________________________________ Xen Security Advisory CVE-2016-7092 / XSA-185 version 3 x86: Disallow L3 recursive pagetable for 32-bit PV guests UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= On real hardware, a 32-bit PAE guest must leave the USER and RW bit clear in L3 pagetable entries, but the pagetable walk behaves as if they were set. (The L3 entries are cached in processor registers, and don't actually form part of the pagewalk.) When running a 32-bit PV guest on a 64-bit Xen, Xen must always OR in the USER and RW bits for L3 updates for the guest to observe architectural behaviour. This is unsafe in combination with recursive pagetables. As there is no way to construct an L3 recursive pagetable in native 32-bit PAE mode, disallow this option in 32-bit PV guests. IMPACT ====== A malicious 32-bit PV guest administrator can escalate their privilege to that of the host. VULNERABLE SYSTEMS ================== All versions of Xen are vulnerable. Only 64-bit builds of the hypervisor are vulnerable. For Xen 4.3 and earlier, 32-bit builds of the hypervisor are not vulnerable. The vulnerability is only exposed to 32-bit PV guests on x86 hardware. The vulnerability is not exposed to 64-bit PV guests, x86 HVM guests, or ARM guests. MITIGATION ========== Running only 64-bit PV or HVM guests will avoid this vulnerability. CREDITS ======= This issue was found in parallel by multiple discoverers, who each disclosed it to the Xen Project Security Team. The first report to us was made by Jérémie Boutoille of Quarkslab. The second report, one working day later, by Shangcong Luan of Alibaba Cloud. RESOLUTION ========== Applying the attached patch resolves this issue. xsa185.patch xen-unstable - Xen 4.4 $ sha256sum xsa185* 3328a1953ecdf4de35462ea8396b0927171d718e95f73a87a7f651427bd8f8b4 xsa185.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-2016-7093 / XSA-186 version 4 x86: Mishandling of instruction pointer truncation during emulation UPDATES IN VERSION 4 ==================== Public release. ISSUE DESCRIPTION ================= When emulating HVM instructions, Xen uses a small i-cache for fetches from guest memory. The code that handles cache misses does not check if the address from which it fetched lies within the cache before blindly writing to it. As such it is possible for the guest to overwrite hypervisor memory. It is currently believed that the only way to trigger this bug is to use the way that Xen currently incorrectly wraps CS:IP in 16 bit modes. The included patch prevents such wrapping. IMPACT ====== A malicious HVM guest administrator can escalate their privilege to that of the host. VULNERABLE SYSTEMS ================== Xen versions 4.7.0 and later are vulnerable. Xen releases 4.6.3 and 4.5.3 are vulnerable. Xen releases 4.6.0 to 4.6.2 inclusive are NOT vulnerable. Xen releases 4.5.2 and earlier are NOT vulnerable. The vulnerability is only exposed to HVM guests on x86 hardware. The vulnerability is not exposed to x86 PV guests, or ARM guests. MITIGATION ========== Running only PV guests will avoid this vulnerability. CREDITS ======= This issue was discovered by Brian Marcotte. RESOLUTION ========== Applying the first patch will resolve the issue. Users wishing to independently verify the correctness of the fix may find the second patch helpful. The second patch makes it easier to use the "fep" (Force Emulation Prefix) feature to reproduce the erroneous condition in a test environment. The "fep" feature requires explicit enablement on the hypervisor command line, and is unsuitable for production systems. Accordingly, applying the second patch does not affect production systems and does not improve security. Xen version First patch Second patch xen-unstable: xsa186-0001-*.patch xsa186-0002-*.patch Xen 4.7.x: xsa186-0001-*.patch xsa186-4.7-0002-*.patch Xen 4.6.3: xsa186-0001-*.patch xsa186-4.6-0002-*.patch Xen 4.5.3: xsa186-0001-*.patch xsa186-4.6-0002-*.patch $ sha256sum xsa186* f2082a36d968a47e477bb5082d0e0aaa58e6cb3dc20b26389f043a9b7b595fa6 xsa186-0001-x86-emulate-Correct-boundary-interactions-of-emulate.patch 412fa58edcbd1c7fdbfec7e28898cf98585593e6a24ccfb088dc0b84715286a5 xsa186-0002-hvm-fep-Allow-testing-of-instructions-crossing-the-1.patch 7482a823c3443e26dee1111c4904162845eaa9f826aa7bf8348007406d91bddd xsa186-4.6-0002-hvm-fep-Allow-testing-of-instructions-crossing-the.patch 5a826a32763d82ac83c924f8c89d12aae5f069a4cbc7d5193aa8413a02b6dc05 xsa186-4.7-0002-hvm-fep-Allow-testing-of-instructions-crossing-the.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-2016-7094 / XSA-187 version 3 x86 HVM: Overflow of sh_ctxt->seg_reg[] UPDATES IN VERSION 3 ==================== Fix the backports xsa187-4.6-0002-*.patch and xsa187-4.4-0002-*.patch. In v1 and v2 these did not compile in debug builds. (Debug builds should not be used in production.) Public release. ISSUE DESCRIPTION ================= x86 HVM guests running with shadow paging use a subset of the x86 emulator to handle the guest writing to its own pagetables. There are situations a guest can provoke which result in exceeding the space allocated for internal state. IMPACT ====== A malicious HVM guest administrator can cause Xen to fail a bug check, causing a denial of service to the host. VULNERABLE SYSTEMS ================== All versions of Xen are vulnerable. The vulnerability is only exposed to HVM guests on x86 hardware, which are configured to run with shadow paging. The vulnerability is not exposed to x86 PV guests, x86 HVM guests running with hardware assisted paging, or ARM guests. x86 HVM guests run in HAP mode by default on modern CPUs. To discover whether your HVM guests are using HAP, or shadow page tables: request debug key `q' (from the Xen console, or with `xl debug-keys q'). This will print (to the console, and visible in `xl dmesg'), debug information for every domain, containing something like this: (XEN) General information for domain 2: (XEN) refcnt=1 dying=2 pause_count=2 (XEN) nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0 dirty_cpus={} max_pages=262400 (XEN) handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=00000000 (XEN) paging assistance: hap refcounts translate external ^^^ The presence of `hap' here indicates that the host is not vulnerable to this domain. For an HVM domain the presence of `shadow' indicates that the domain can exploit the vulnerability. MITIGATION ========== Running only PV guests will avoid this vulnerability. On hardware which supports Hardware Assisted Paging, configuring the guests to not run with shadow paging will avoid this vulnerability. CREDITS ======= This issue was discovered by Andrew Cooper of Citrix. RESOLUTION ========== Applying the first patch will resolve this issue. The second patch provides additional assurance that the vulnerability is truly eliminated and that there are no related problems. If hotpatching, applying only the first patch is recommended since the second patch is awkward for hotpatching. If deploying new builds, applying both patches is recommended. Xen version First patch Second patch xen-unstable: xsa187-0001-*.patch xsa187-0002-*.patch Xen 4.7.x: xsa187-4.7-0001-*.patch xsa187-4.7-0002-*.patch Xen 4.6.x: xsa187-4.7-0001-*.patch xsa187-4.6-0002-*.patch Xen 4.5.x: xsa187-4.7-0001-*.patch xsa187-4.6-0002-*.patch Xen 4.4.x: xsa187-4.7-0001-*.patch xsa187-4.4-0002-*.patch $ sha256sum xsa187* 65205ee195699d65884af04083ffb86c6ddbc96cbca3141c87f6b2d671de45a3 xsa187-0001-x86-shadow-Avoid-overflowing-sh_ctxt-seg_reg.patch f90e6d13385fb9219e1e26e3a148d1670aefc7130e0639415d08bbb6a1d9efee xsa187-0002-x86-segment-Bounds-check-accesses-to-emulation-ctxt-.patch 727b18ae83001f7ea04613aa7199ada3e6a84939aa44516f7c426e609d383b2a xsa187-4.4-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch b96731379ea77d49ffff31d969f4742dde985ef7a86af9422dcac8327c2a1916 xsa187-4.6-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch be9fe85d36c2c1fbca246c1f4d834c3ef11b6ab3d5467da0ac8c079aa5a68de9 xsa187-4.7-0001-x86-shadow-Avoid-overflowing-sh_ctxt-seg.patch 36b22d6a168be39f31a1c1304f708269a2a10fe5105f7da4a06877d6059f1cd6 xsa187-4.7-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the "reconfigure to use HAP" MITIGATION is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because the mitigation result in guest-visible changes. Deployment of this mitigation is permitted only AFTER the embargo ends. Deployment of the PATCHES 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-2016-7154 / XSA-188 version 3 use after free in FIFO event channel code UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= When the EVTCHNOP_init_control operation is called with a bad guest frame number, it takes an error path which frees a control structure without also clearing the corresponding pointer. Certain subsequent operations (EVTCHNOP_expand_array or another EVTCHNOP_init_control), upon finding the non-NULL pointer, continue operation assuming it points to allocated memory. IMPACT ====== A malicious guest administrator can crash the host, leading to a DoS. Arbitrary code execution (and therefore privilege escalation), and information leaks, cannot be excluded. VULNERABLE SYSTEMS ================== Only Xen 4.4 is vulnerable. Xen versions 4.5 and later as well as Xen versions 4.3 and earlier are not vulnerable. MITIGATION ========== There is no mitigation available. CREDITS ======= This issue was discovered by Mikhail Gorobets of Advanced Threat Research, Intel Security. RESOLUTION ========== Applying the attached patch resolves this issue. xsa188.patch Xen 4.4.x $ sha256sum xsa188* 9f374c2e1437ad71369f41275e7b333e7b7691a783ba693ee567c899bd78c722 xsa188.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. ========================================================== Serveur de référence du CERT-Renater https://services.renater.fr/ssi/ ========================================================== + 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 + ==========================================================