==================================================================== CERT-Renater Note d'Information No. 2016/VULN399 _____________________________________________________________________ DATE : 28/11/2016 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-191.html https://xenbits.xen.org/xsa/advisory-192.html https://xenbits.xen.org/xsa/advisory-193.html ____________________________________________________________________ Xen Security Advisory CVE-2016-9386 / XSA-191 version 3 x86 null segments not always treated as unusable UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The Xen x86 emulator erroneously failed to consider the unusability of segments when performing memory accesses. The intended behaviour is as follows: The user data segment (%ds, %es, %fs and %gs) selectors may be NULL in 32-bit to prevent access. In 64-bit, NULL has a special meaning for user segments, and there is no way of preventing access. However, in both 32-bit and 64-bit, a NULL LDT system segment is intended to prevent access. On Intel hardware, loading a NULL selector zeros the base as well as most attributes, but sets the limit field to its largest possible value. On AMD hardware, loading a NULL selector zeros the attributes, leaving the stale base and limit intact. Xen may erroneously permit the access using unexpected base/limit values. Ability to exploit this vulnerability on Intel is easy, but on AMD depends in a complicated way on how the guest kernel manages LDTs. IMPACT ====== An unprivileged guest user program may be able to elevate its privilege to that of the guest operating system. VULNERABLE SYSTEMS ================== The vulnerability is only exposed to HVM guests. ARM systems are NOT vulnerable. All versions of Xen are affected. However, we believe that the vulnerability cannot be exploited on Xen 4.7 by completely unprivileged guest processes, unless the VM has been explicitly configured with a non-default cpu vendor string (in xm/xl, this would be done with a `cpuid=' domain config option). MITIGATION ========== Running only PV guests will avoid this issue. CREDITS ======= This issue was discovered by Andrew Cooper of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa191.patch xen-unstable, Xen 4.7.x xsa191-4.6.patch Xen 4.6.x, Xen 4.5.x, Xen 4.4.x $ sha256sum xsa191* dca534cf4d3711ea8797846a18238ca16cc9e7a24a887300db22c3ba3d95c199 xsa191.patch d95a1f0dd5c45497ca56e2e1390fc688bf0a4a7a7fd10c65ae25b4bbb3353b69 xsa191-4.6.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-9382 / XSA-192 version 3 x86 task switch to VM86 mode mis-handled UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= LDTR, just like TR, is purely a protected mode facility. Hence even when switching to a VM86 mode task, LDTR loading needs to follow protected mode semantics. This was violated by the code. IMPACT ====== On SVM (AMD hardware): a malicious unprivileged guest process can escalate its privilege to that of the guest operating system. On both SVM and VMX (Intel hardware): a malicious unprivileged guest process can crash the guest. VULNERABLE SYSTEMS ================== Only 32-bit x86 HVM guests are vulnerable. Furthermore, only guest operating systems which actually make use of hardware task switching, and allow a new task to start in VM86 mode, are vulnerable. We are not aware of any such operating systems. The vulnerability is NOT exposed on any PV guests. The vulnerability is NOT exposed on any 64-bit guests, ARM systems are NOT vulnerable. Xen versions from 4.0 onwards are affected. Xen versions 3.4 and earlier are not affected. MITIGATION ========== For guests which are affected, the vulnerability could possibly be mitigated by disabling access to VM86 mode by unprivileged guest programs. Details would depend on the (so far hypothetical) vulnerable guest kernel. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa192.patch xen-unstable, Xen 4.7.x, Xen 4.6.x xsa192-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa192* 687b0216eefd5ecef8a3135cc6f542cb3d9ff35e8e9696a157703e84656c35e8 xsa192.patch bb0c6622c6f5c5eb9a680020d865802069446830b4a170bcb82336f6c3b77f55 xsa192-4.5.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-9385 / XSA-193 version 3 x86 segment base write emulation lacking canonical address checks UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Both writes to the FS and GS register base MSRs as well as the WRFSBASE and WRGSBASE instructions require their input values to be canonical, or a #GP fault will be raised. When the use of those instructions by the hypervisor was enabled, the previous guard against #GP faults (having recovery code attached) was accidentally removed. IMPACT ====== A malicious guest administrator can crash the host, leading to a DoS. VULNERABLE SYSTEMS ================== Xen versions 4.4 and onwards are affected. Xen versions 4.3 and earlier are not affected. The vulnerability is only exposed to x86 PV guests. The vulnerability is NOT exposed to x86 HVM guests. ARM systems are NOT vulnerable. MITIGATION ========== Running only HVM guests will avoid this vulnerability. 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. xsa193.patch xen-unstable xsa193-4.7.patch Xen 4.7.x, Xen 4.6.x xsa193-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa193* 401df29b462a3430403a4f5bb36fd7824e692c9b5bac650e1a9d70bd440a55a1 xsa193.patch b3494b1fe5fefc0d032bd603340e364c880ec0d3ae3fb8aa3a773038e956f955 xsa193-4.5.patch f1b0092c585ebffe83d6ed7df94885ec5dfcb4227bdb33f421bad9febb8135a1 xsa193-4.7.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 ========================================================== 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 + ==========================================================