==================================================================== CERT-Renater Note d'Information No. 2020/VULN370 _____________________________________________________________________ DATE : 07/07/2020 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-328.html https://xenbits.xen.org/xsa/advisory-327.html https://xenbits.xen.org/xsa/advisory-321.html https://xenbits.xen.org/xsa/advisory-319.html https://xenbits.xen.org/xsa/advisory-317.html _____________________________________________________________________ Xen Security Advisory CVE-2020-15567 / XSA-328 version 3 non-atomic modification of live EPT PTE UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes. Depending on the compiler version and optimisation flags, Xen might expose a dangerous partially-written PTE to the hardware, which an attacker might be able to race to exploit. IMPACT ====== A guest administrator or perhaps even unprivileged guest user might be able to cause denial of service, data corruption, or privilege escalation. VULNERABLE SYSTEMS ================== Only systems using Intel CPUs are vulnerable. Sytems using AMD CPUs, and Arm systems, are not vulnerable. Only systems using nested paging ("hap", aka nested paging, aka in this case Intel EPT) are vulnerable. Only HVM and PVH guests can exploit the vulnerability. The presence and scope of the vulnerability depends on the precise optimisations performed by the compiler used to build Xen. If the compiler generates (a) a single 64-bit write, or (b) a series of read-modify-write operations which are in the same order as the source code, the hypervisor is not vulnerable. For example, in one test build with gcc 8.3 with normal settings, the compiler generated multiple (unlocked) read-modify-write operations in source code order, which did *not* constitute a vulnerability. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code generation options). The code clearly violates the C rules. So we have chosen to issue this advisory. MITIGATION ========== Running only PV guests will avoid this vulnerability. Switching to shadow paging (e.g. using the "hap=0" xl domain domain configuration file parameter) will avoid exposing the vulnerability to those guests. Manual inspection of the generated assembly code might allow a suitably qualified person to say that a particular build is not vulnerable. There is no less broad mitigation. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. For patch 1: Reviewed-by: Roger Pau Monné For patch 2: From: Roger Pau Monné Reported-by: Jan Beulich Signed-off-by: Roger Pau Monné RESOLUTION ========== Applying the appropriate pair of attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa328/xsa328-?.patch xen-unstable xsa328/xsa328-4.13-?.patch Xen 4.13.x xsa328/xsa328-4.12-?.patch Xen 4.12.x xsa328/xsa328-4.11-?.patch Xen 4.11.x, Xen 4.10.x xsa328/xsa328-4.9-?.patch Xen 4.9.x $ sha256sum xsa328* xsa328*/* 61ceb3d039c3ebb06f480a17593b367b01e7c1e5cc3669d77caecb704fbc7071 xsa328.meta cae53f7e6c46fe245790036279bc50eaa10e4271790e871ad8a7d446629b2e12 xsa328/xsa328-1.patch d61354a992869451cd7a3c92254672b5e253d1a994135cf9b4a5c784be0a07ef xsa328/xsa328-2.patch 018412fba6f153c1d6b03fc2fa6f3ac381060efe6a8651404462028d24c830a8 xsa328/xsa328-4.9-1.patch f3deb26e0ce27c385ab16065a0ba67b86a228afd949c0a6a78b9d48366fc2554 xsa328/xsa328-4.9-2.patch a600ecef784485e8608cd4549f756ffa24705747a4d876147f9ba64fff118580 xsa328/xsa328-4.11-1.patch f3deb26e0ce27c385ab16065a0ba67b86a228afd949c0a6a78b9d48366fc2554 xsa328/xsa328-4.11-2.patch d608921359e561f9c594c9f8f7ee02432518a229ecea638d472ab91227d705ec xsa328/xsa328-4.12-1.patch a51162c019e7e6ed394faa7d40c932456059b7b76a784dc7886dd0a47c43da0b xsa328/xsa328-4.12-2.patch 51a41fae885aed40839887da473e0c8ab4c4d897a121f5fac2cc3c6c0188d6d2 xsa328/xsa328-4.13-1.patch a51162c019e7e6ed394faa7d40c932456059b7b76a784dc7886dd0a47c43da0b xsa328/xsa328-4.13-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 CVE-2020-15564 / XSA-327 version 3 Missing alignment check in VCPUOP_register_vcpu_info UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be mapped into Xen address space so it can be directly accessed. On Arm, the region is accessed with instructions which require a specific alignment. Unfortunately, there is no check that the address provided by the guest will be correctly aligned. As a result, a malicious guest could cause a hypervisor crash by passing a misaligned address. IMPACT ====== A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS ================== All Xen versions are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected. MITIGATION ========== There is no mitigation. CREDITS ======= This issue was discovered by Julien Grall of Amazon. RESOLUTION ========== Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa327.patch Xen 4.9 - xen-unstable $ sha256sum xsa327* f046eefcc1368708bd1fafc88e063d3dbc5c4cdb593d68b3b04917c6cdb7bcb5 xsa327.meta 1d057695d5b74ce2857204103e943caeaf773bc4fb9d91ea78016e01a9147ed7 xsa327.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patch 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-2020-15565 / XSA-321 version 3 insufficient cache write-back under VT-d UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= When page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs. Furthermore, IOMMUs may be non-coherent, and hence prior to flushing IOMMU TLBs CPU cached also needs writing back to memory after changes were made. Such writing back of cached data was missing in particular when splitting large page mappings into smaller granularity ones. IMPACT ====== A malicious guest may be able to retain read/write DMA access to frames returned to Xen's free pool, and later reused for another purpose. Host crashes (leading to a Denial of Service) and privilege escalation cannot be ruled out. VULNERABLE SYSTEMS ================== Xen versions from at least 3.2 onwards are affected. Only x86 Intel systems are affected. x86 AMD as well as Arm systems are not affected. Only x86 HVM guests using hardware assisted paging (HAP), having a passed through PCI device assigned, and having page table sharing enabled can leverage the vulnerability. Note that page table sharing will be enabled (by default) only if Xen considers IOMMU and CPU large page size support compatible. MITIGATION ========== Suppressing the use of page table sharing will avoid the vulnerability (command line option "iommu=no-sharept"). Note however that as of Xen version 4.13 there's also a respective per-guest control ("passthrough=" libxl guest config file option). If any guests have been created with an explicit setting here, this setting may conflict with the addition of the "iommu=no-sharept" Xen command line option. Suppressing the use of large HAP pages will avoid the vulnerability (command line options "hap_2mb=no hap_1gb=no"). Not passing through PCI devices to HVM guests will avoid the vulnerability. CREDITS ======= This issue was discovered by Roger Pau Monné of Citrix. RESOLUTION ========== Applying the appropriate set of attached patches resolves this issue. Note that unlike implied by the numbering, the patches here are intended to go on top of XSA-328's. Note also that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa321/xsa321-?.patch xen-unstable xsa321/xsa321-4.13-?.patch Xen 4.13.x xsa321/xsa321-4.12-?.patch Xen 4.12.x xsa321/xsa321-4.11-?.patch Xen 4.11.x xsa321/xsa321-4.10-?.patch Xen 4.10.x xsa321/xsa321-4.9-?.patch Xen 4.9.x $ sha256sum xsa321* xsa321*/* f0824c6b6e5de723301223927dbad916e0e5fbeb70f30a7e2467a04094dd840b xsa321.meta 35ed3be5e66da0580de8fb14ee7e6c073ac60e08e022c35ef194a714698641ad xsa321/xsa321-1.patch b2bbb4cf397b7b532dcab120a4d678938c50ca0df6ff2724a416ac8567bd667b xsa321/xsa321-2.patch 87d2e0446ee3fb013c8f307e71c0ddeae8122d6beee3e5d2871aa429d8d19daa xsa321/xsa321-3.patch 38d7e715d4ed751a9ce503b61cacaf2d06c91b2eab4be95cbc3a9ae4d2a05efb xsa321/xsa321-4.9-1.patch e4d5238233c883ea62491f852e543550bce9d74d7239a866f5e117df46838abc xsa321/xsa321-4.9-2.patch d9140aee60c848e2e07a59741bab1fde4669f2627923e5d3f08b8f2971f589c4 xsa321/xsa321-4.9-3.patch be8e320f64185bb29c52c0c1472d9d9aa1319768076ff70e691d4b40f7938a27 xsa321/xsa321-4.9-4.patch 7d83cb2d7de293f8534fa4eae1c56979984d01d8842ac06cfcb645191f27e51f xsa321/xsa321-4.9-5.patch 99c7cf186f0fea47ef516e3d477a5f5068adaad44624b406694b9ff33268e05b xsa321/xsa321-4.9-6.patch 9731286e9af9d83c5bf191aa5a6be0dfa34c79bca15660cd9b9e1c8e930cf974 xsa321/xsa321-4.9-7.patch 360765e859866c466dc1c9c6893dd800407d8f09b0b6f2b07fa403c290c4f0c6 xsa321/xsa321-4.10-1.patch e4d5238233c883ea62491f852e543550bce9d74d7239a866f5e117df46838abc xsa321/xsa321-4.10-2.patch 74b5c19a469cc7252a296cb19288f1ab53a411530d06dd364a0e3292c6aa273f xsa321/xsa321-4.10-3.patch be8e320f64185bb29c52c0c1472d9d9aa1319768076ff70e691d4b40f7938a27 xsa321/xsa321-4.10-4.patch 7d83cb2d7de293f8534fa4eae1c56979984d01d8842ac06cfcb645191f27e51f xsa321/xsa321-4.10-5.patch 99c7cf186f0fea47ef516e3d477a5f5068adaad44624b406694b9ff33268e05b xsa321/xsa321-4.10-6.patch fb3122d23ae7381d798721fe92c622ea2d37baac369fe89b0707030315dfc896 xsa321/xsa321-4.10-7.patch 360765e859866c466dc1c9c6893dd800407d8f09b0b6f2b07fa403c290c4f0c6 xsa321/xsa321-4.11-1.patch 02e2fda4b467f10a7f38cb2a095b9da04289d9e8489db88bf542d6527b823a23 xsa321/xsa321-4.11-2.patch 04c9bc347f8d3cbb8aecede370189bba2ed47be560d1871b91eb01b962a578cc xsa321/xsa321-4.11-3.patch be8e320f64185bb29c52c0c1472d9d9aa1319768076ff70e691d4b40f7938a27 xsa321/xsa321-4.11-4.patch c1b143b43b59244d5dc755f6a99de70ac39e803a7204296bb47300b9ffe26e59 xsa321/xsa321-4.11-5.patch 38456ff553416e48f2f5438c2a5a163b20929e8a58dbe811942d0d47aacfc9ea xsa321/xsa321-4.11-6.patch d3b6df41682e6b88898545590bee8242c00b4593773ba8070ce57a0473094189 xsa321/xsa321-4.11-7.patch c6d00d7a988002687be9a19a2d631c3562d8ec9f02ae24efc23eb0039f9e0ddb xsa321/xsa321-4.12-1.patch 64dd3aa18be3ccb17ab6d813df16e2025adabbe38127f2f00175a6a481651d86 xsa321/xsa321-4.12-2.patch 935346f3d0f2759699b0ccb8002abfb0dc173ec3ed616fb9042ad86751445757 xsa321/xsa321-4.12-3.patch be8e320f64185bb29c52c0c1472d9d9aa1319768076ff70e691d4b40f7938a27 xsa321/xsa321-4.12-4.patch c1b143b43b59244d5dc755f6a99de70ac39e803a7204296bb47300b9ffe26e59 xsa321/xsa321-4.12-5.patch 0da20aeb89e18490d60649dbfdb9c374e5861032da784a7724216c329f2cc5f0 xsa321/xsa321-4.12-6.patch 4d1954600eeca7e2cb9143ea8e32969731071f991a9a88a245c18e860c57c22c xsa321/xsa321-4.12-7.patch 946053a8bba53d87b4164acaf3343e30689d91b505b6355d873c016166d87103 xsa321/xsa321-4.13-1.patch f09e8cbf0cce17647d47f38137792517c8b108c3b54f57793d03578b0d5ccf99 xsa321/xsa321-4.13-2.patch bd50ad52d23c6fc12b69ecaaf41073833cbe9b1d66a9f4e148df078e30dd45d4 xsa321/xsa321-4.13-3.patch b181511962ce397302be8b7d5a130abe0995b3fda68b96f1afa95ae64f62dd09 xsa321/xsa321-4.13-4.patch 3286fc184fb377c1ce94344d1dbae3b78e95b0ae766eabb80b2fc612e59ffb69 xsa321/xsa321-4.13-5.patch 03a193197d176109dc586f4d6a76aebe32a4aa147e88c79d57582cf0a186c4ef xsa321/xsa321-4.13-6.patch ef7f9ac74313d2dabfb258b2519b2144e4feed3c85b5f705c4b1b7ba31ec316a xsa321/xsa321-4.13-7.patch e6d4b77063d4cd7a7242ac54b150ce42ce684ecbf46c7eaff5715976f272f4bc xsa321/xsa321-4.patch 920771be10110a3eef8e4b8644145794d274042092f3aa14e04fa94fc1e78e8a xsa321/xsa321-5.patch b10c5583e01f1c26862806562f30e393960b0bbdd7cf7fca6640f4daa88fe017 xsa321/xsa321-6.patch 18da003fb05b7aebe868ff9f1c77063b8a51be3b07ab0c9fc4821bf46ca86eeb xsa321/xsa321-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 _____________________________________________________________________ Xen Security Advisory CVE-2020-15563 / XSA-319 version 3 inverted code paths in x86 dirty VRAM tracking UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make Xen de-reference a pointer guaranteed to point at unmapped space. IMPACT ====== A malicious or buggy HVM guest may cause the hypervisor to crash, resulting in Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS ================== Xen versions from 4.8 onwards are affected. Xen versions 4.7 and earlier are not affected. Only x86 systems are affected. Arm systems are not affected. Only x86 HVM guests using shadow paging can leverage the vulnerability. In addition there needs to be an entity actively monitoring a guest's video frame buffer (typically for display purposes) in order for such a guest to be able to leverage the vulnerability. x86 PV guests as well as x86 HVM guest using hardware assisted paging (HAP) cannot leverage the vulnerability. MITIGATION ========== Running only PV guests will avoid the vulnerability. For HVM guest explicitly configured to use shadow paging (e.g. via the `hap=0' xl domain configuration file parameter), changing to HAP (e.g. by setting `hap=1') will avoid exposing the vulnerability to those guests. HAP is the default (in upstream Xen), where the hardware supports it; so this mitigation is only applicable if HAP has been disabled by configuration. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa319.patch xen-unstable, 4.13 - 4.9 $ sha256sum xsa319* 1fe0dc2e274776b8e1275f85129280f280f94ca4eabe6a8166113283dad93ed8 xsa319.meta c145f394f8ac7d8838c376a97e1850c4125c12e478fc66ebe025ae397b27e6ea xsa319.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patch described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER deployment of the "use HAP mode" mitigation described above 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 in that case the configuration change can be observed by guests, which could lead to the rediscovery of the vulnerability. 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-2020-15566 / XSA-317 version 3 Incorrect error handling in event channel port allocation UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The allocation of an event channel port may fail for multiple reasons: 1) Port is already in use 2) The memory allocation failed 3) The port we try to allocate is higher than what is supported by the ABI (e.g 2L or FIFO) used by the guest or the limit set by an administrator ('max_event_channels' in xl cfg). Due to the missing error checks, only 1) will be considered as an error. All the other cases will provide a "valid" port and will result to a crash when trying to access the event channel. IMPACT ====== When the administrator configured a guest to allow more than 1023 event channels, that guest may be able to crash the host. When Xen is out-of-memory, allocation of new event channels will result in crashing the host rather than reporting an error. VULNERABLE SYSTEMS ================== Xen versions 4.10 and later are affected. (The special Xen 4.8 "Comet" branch for XSA-254 contains changes similar to those which led to this vulnerability; so it is likely to be affected, but - like mainline Xen 4.8 - that branch is longer security-supported.) Older Xen versions are unaffected. All architectures are affected. The default configuration, when guests are created with xl/libxl, is not vulnerable, because of the default event channel limit (see Mitigation, below). MITIGATION ========== The problem can be avoided by reducing the number of event channels available to the guest no more than 1023. For example, setting "max_event_channels=1023" in the xl domain configuration, or deleting any existing setting (since 1023 is the default for xl/libxl). For ARM systems, any limit no more than 4095 is safe. For 64-bit x86 PV guests, any limit no more than 4095 is likewise safe if the host configuration prevents the guest administrator from substituting and running a 32-bit kernel (and thereby putting the guest into 32-bit PV mode). CREDITS ======= This issue was discovered by Amazon. RESOLUTION ========== Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa317.patch Xen 4.10 - xen-unstable $ sha256sum xsa317* 11e77dd8644cee40cee609d02e27d70655f3999005cae8c24fb2801980ebb4f2 xsa317.meta 17908035e2da07f6070fa8de345db68c96ed9bd78f8b114e43ba0194c1be3f15 xsa317.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the *patch* 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). And: deployment of the event channel limit reduction 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 such a change can be visible to the guest, so it would leak the preconditions for the vulnerability and maybe lead to rediscovery. Deployment of this, or similar mitigations, is permitted only AFTER the embargo ends. 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 + =========================================================