==================================================================== CERT-Renater Note d'Information No. 2018/VULN393 _____________________________________________________________________ DATE : 22/11/2018 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-275.html https://xenbits.xen.org/xsa/advisory-276.html https://xenbits.xen.org/xsa/advisory-277.html https://xenbits.xen.org/xsa/advisory-279.html https://xenbits.xen.org/xsa/advisory-280.html _____________________________________________________________________ Xen Security Advisory XSA-275 version 2 insufficient TLB flushing / improper large page mappings with AMD IOMMUs UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= In order to be certain that no undue access to memory is possible anymore after IOMMU mappings of this memory have been removed, Translation Lookaside Buffers (TLBs) need to be flushed after most changes to such mappings. Xen bypassed certain IOMMU flushes on AMD x86 hardware. Furthermore logic exists Xen to re-combine small page mappings into larger ones. Such re-combination could have occured in cases when it was not really safe/correct to do so. IMPACT ====== A malicious or buggy guest may be able to escalate its privileges, may cause a Denial of Service (DoS) affecting the entire host, or may be able to access data it is not supposed to access (information leak). VULNERABLE SYSTEMS ================== Xen versions from at least 3.2 onwards are affected. Note that the situation is worse in 4.1 and earlier, in that there's no flushing of the TLB at all. Only systems with AMD x86 hardware with enabled IOMMU are affected. ARM and Intel x86 systems, and AMD x86 systems without enabled IOMMU, are not affected. Only systems where physical PCI devices are assigned to untrusted guests are vulnerable. MITIGATION ========== There is no known mitigation for affected system/guest combinations. CREDITS ======= This issue was discovered by Paul Durrant of Citrix. RESOLUTION ========== Applying the appropriate set of attached patches resolves this issue. xsa275-?.patch xen-unstable xsa275-4.11-?.patch Xen 4.11.x ... Xen 4.8.x xsa275-4.7-?.patch Xen 4.7.x $ sha256sum xsa275* b5a02598cd2cffcc2cb59c724eeabb50220fa55f2cbe571726a5228909bf7bfe xsa275.meta 7a3360e61fbb088f7d9f2b92921c9dceb08a1e01563c42ba4cf4a9999fe42fc4 xsa275-1.patch 4783a3abd2d87386ce9a7b790666ad398c5e027a6a146fce6424f0bcbfd8a7c6 xsa275-2.patch 49844d06f24ea129f1a501b4b0d5cb6ec3b288f3a2b41377ce793cc6fc81a788 xsa275-4.7-1.patch 7ea8bf2ff2c8c92cb064a70959a1148229c4577109015bd5aab72603ccb8f7e3 xsa275-4.7-2.patch 15d1aa7528368ed92caf8ea9baf77a406e1de26d0697dafd8a85da0d66eb95dc xsa275-4.11-1.patch 0806e8c904ac9e8eb89404dffd227fcd56da84b7eb0150ee1e9b4bee54a05b4e xsa275-4.11-2.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-276 version 2 resource accounting issues in x86 IOREQ server handling UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Allocation of pages used to communicate with external emulators did not follow certain principles that are required for proper life cycle management of guest exposed pages. IMPACT ====== A compromised DM stubdomain may cause Xen to crash, resulting in a DoS (Denial of Service) affecting the entire host. Privilege escalation as well as information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== Only Xen 4.11 is affected by this vulnerability. Xen 4.10 and older are not affected by this vulnerability. Only systems running HVM guests with their devicemodels in a stubdomain are considered vulnerable. Note that attackers also need to exploit the devicemodel in order to have access to this vulnerability. Arm guests cannot leverage this vulnerability. MITIGATION ========== Running only PV guests will avoid this vulnerability. (The security of a Xen system using stub domains 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.) CREDITS ======= This issue was discovered by Julien Grall of ARM. RESOLUTION ========== Applying the appropriate set of attached patches resolves this issue. xsa276/*.patch xen-unstable xsa276-4.11/*.patch Xen 4.11.x $ sha256sum xsa276* xsa276*/* efe9f031c5646b111cbfbe35141a7d99eb31ead07c1c6051145abbd9a3def5b9 xsa276.meta 7f77225e3de780a2507714caab5870664634bf9f76215547bebd31a6399a86ef xsa276-4.11/0001-x86-hvm-ioreq-fix-page-referencing.patch c93c66090009833cd11fabe72b523cbdb3467fa104cc97d1855d365881aa7f8e xsa276-4.11/0002-x86-hvm-ioreq-use-ref-counted-target-assigned-shared.patch ef8b89375866821f4a612f600d10834bf65d811b1784a4ee0fde4a3a409501e0 xsa276/0001-x86-hvm-ioreq-fix-page-referencing.patch 75398ec343b9aaebf0c7dc0c5ef5ed7a3f3be0959f1519db5c7f32c44e7a54d3 xsa276/0002-x86-hvm-ioreq-use-ref-counted-target-assigned-shared.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-277 version 2 x86: incorrect error handling for guest p2m page removals UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The internal function querying a domain's p2m table grabs the p2m lock by default, so that the answer to the query remains true until the caller can act on that information; it is up to the caller then to release the lock. Unfortunately, certain failure paths don't release the lock. IMPACT ====== A malicious or buggy guest may cause a deadlock, resulting in a DoS (Denial of Service) affecting the entire host. VULNERABLE SYSTEMS ================== Xen 4.11 and onward are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only systems running untrusted HVM or PVH guests are vulnerable. Systems running only PV guests are not vulnerable. MITIGATION ========== Running only PV guests will avoid this vulnerability. CREDITS ======= This issue was discovered by Paul Durrant of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa277.patch xen-unstable, Xen 4.11.x $ sha256sum xsa277* 576cdc05975e43698624b88f7290119dd702b3db8f30f3219754d992d7fef0c6 xsa277.meta c9025e1daaec4081a61f1ed7b96e69cfe8e35bdd5b4fcc0fadc98f71c2e243e2 xsa277.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-279 version 2 x86: DoS from attempting to use INVPCID with a non-canonical addresses UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The INVPCID instruction raises #GP[0] if an attempt is made to invalidate a non-canonical address. Older flushing mechanisms such as INVLPG tolerate this without error, and perform no action. There is one guest accessible path in Xen where a non-canonical address was passed into the TLB flushing code. This previously had no ill effect, but became vulnerable with the introduction of PCID to reduce the performance hit from the Meltdown mitigations. IMPACT ====== A buggy or malicious PV guest can crash the host. VULNERABLE SYSTEMS ================== Only hardware which supports the INVPCID instruction is vulnerable. This is available on Intel Haswell processors and later. AMD x86 processors are not known to support this instruction, and ARM processors are entirely unaffected. Only versions of Xen with PCID support are vulnerable. Support first appeared in Xen 4.11 but was backported to the stable trees as part of the Meltdown (XSA-254 / CVE-2017-5754) fixes. Xen 4.10.2, 4.9.3, 4.8.4 as well as the stable-4.7 and 4.6 branches are vulnerable. The vulnerability is only exposed to 64-bit PV guests. 32-bit PV guests, as well as HVM/PVH guests cannot exploit the vulnerability. MITIGATION ========== Booting Xen with `pcid=0` or `invpcid=0` on the command line will work around the issue. Alternatively, running untrusted 64bit PV guests inside xen-shim will work around the issue. CREDITS ======= This issue was discovered by Matthew Daley. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa279.patch xen-unstable, Xen 4.11.x, Xen 4.10.x xsa279-4.9.patch Xen 4.9.x ... 4.7.x $ sha256sum xsa279* 40319fcf33348176eb14d7fc7c68c255cc7291013242ea444de6d00602024a11 xsa279.meta 0c1d50effe6645051a15dd83af57088dd4a055e26a23b1fa9e6c3722a7973f5d xsa279.patch fd34f29bc7e53359585135408cbbd12e12a003f59b135e81cc44186c5cddd40d xsa279-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 XSA-280 version 2 Fix for XSA-240 conflicts with shadow paging UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The fix for XSA-240 introduced a new field into the control structure associated with each page of RAM. This field was added to a union, another member of which is used when Xen uses shadow paging for the guest. During migration, or with the L1TF (XSA-273) mitigation for PV guests in effect, the two uses conflict. IMPACT ====== A malicious or buggy x86 PV guest may cause Xen to crash, resulting in a DoS (Denial of Service) affecting the entire host. Privilege escalation as well as information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been checked. Only x86 systems are affected. ARM systems are not affected. Only Xen versions with the XSA-240 fixes applied are vulnerable. Only Xen versions which permit linear page table use by PV guests are vulnerable. Only x86 PV guests can leverage this vulnerability. x86 HVM guests cannot leverage this vulnerability. MITIGATION ========== Not permitting linear page table use by PV guests avoids the vulnerability. This can be done both at build time, by turning off the PV_LINEAR_PT configure option, or at runtime, by passing specifying "pv-linear-pt=0" on the hypervisor command line. On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which have themselves been hardened against L1TF _and_ avoiding live migrating or snapshotting PV guests will generally prevent this issue being triggered. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them 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. Running only HVM guests will avoid this vulnerability. CREDITS ======= This issue was discovered by the security team of Prgmr.com. RESOLUTION ========== Applying the appropriate pair of attached patches resolves this issue. xsa280-?.patch xen-unstable xsa280-1.patch + xsa280-4.11-2.patch Xen 4.11.x xsa280-1.patch + xsa280-4.10-2.patch Xen 4.10.x xsa280-4.9-1.patch + xsa280-4.10-2.patch Xen 4.9.x, Xen 4.8.x xsa280-4.9-1.patch + xsa280-4.7-2.patch Xen 4.7.x $ sha256sum xsa280* ff0b376b9e2ec16f7c15b144d4d38375d6f6b4019aa9c17f6b80f9dfe40319ef xsa280.meta 41b2b91dbabbf2048c790c5934ab696ef53932ff98d1069eb7c7ae52e61cd44b xsa280-1.patch d46e46a6e706e0d3416d40ed12227223f7e8f825dfc63ed203c1df115976e8a1 xsa280-2.patch 163eaf2e16d5cc314a81fa1254eb2809674001b2329c41556a078b7f94e72ced xsa280-4.7-2.patch 22e9d29f316356341db40c743ca59f9bb9d783a58fb6429d5badf57a77b5f34a xsa280-4.9-1.patch ff0a839dbd9347ec88aaeb7ef1145d0cd9029a19c6a478088c63c0959ba0e740 xsa280-4.10-2.patch 87940f3b84d0adfd89e1b2bc1a872ae2948e1621e4994e7879b77e327b0136b5 xsa280-4.11-2.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) EXCEPT the linear page table disabling one is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However deployment of the linear page table disabling 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 altering the set of features usable in a guest in connection with a security issue would be a user-visible change which could lead to the rediscovery of the vulnerability. Also: 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 + =========================================================