==================================================================== CERT-Renater Note d'Information No. 2018/VULN261 _____________________________________________________________________ DATE : 31/08/2018 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== http://xenbits.xen.org/xsa/advisory-273.html http://xenbits.xen.org/xsa/advisory-272.html http://xenbits.xen.org/xsa/advisory-271.html http://xenbits.xen.org/xsa/advisory-270.html http://xenbits.xen.org/xsa/advisory-269.html http://xenbits.xen.org/xsa/advisory-268.html _____________________________________________________________________ Xen Security Advisory CVE-2018-3620,CVE-2018-3646 / XSA-273 L1 Terminal Fault speculative side channel ISSUE DESCRIPTION ================= In x86 nomenclature, a Terminal Fault is a pagetable walk which aborts due to the page being not present (e.g. paged out to disk), or because of reserved bits being set. Architecturally, such a memory access will result in a page fault exception, but some processors will speculatively compute the physical address and issue an L1D lookup. If data resides in the L1D cache, it may be forwarded to dependent instructions, and may be leaked via a side channel. Furthermore: * SGX protections are not applied * EPT guest to host translations are not applied * SMM protections are not applied This issue is split into multiple CVEs depending on circumstance. The CVEs which apply to Xen are: * CVE-2018-3620 - Operating Systems and SMM * CVE-2018-3646 - Hypervisors For more details, see: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html IMPACT ====== An attacker can potentially read arbitrary host RAM. This includes data belonging to Xen, data belonging to other guests, and data belonging to different security contexts within the same guest. An attacker could be a guest kernel (which can manipulate the pagetables directly), or could be guest userspace either directly (e.g. with mprotect() or similar system call) or indirectly (by gaming the guest kernel's paging subsystem). VULNERABLE SYSTEMS ================== Systems running all versions of Xen are affected. Only x86 processors are vulnerable. ARM processors are not known to be affected. Only Intel Core based processors (from at least Merom onwards) are potentially affected. Other processor designs (Intel Atom/Knights range), and other manufacturers (AMD) are not known to be affected. x86 PV guests fall into the CVE-2018-3620 (OS and SMM) category. x86 HVM and PVH guests fall into the CVE-2018-3646 (Hypervisors) category. MITIGATION ========== This issue can be mitigated with a combination of software and firmware changes. Switching guests to being HVM with shadow paging enabled (hap=0 in xl.cfg) is believed to mitigate the vulnerability on systems which don't have terabytes of RAM. However the performance impact of shadow paging in combination with in-guests Meltdown mitigations (KPTI, KVAS, etc) will most likely make this option prohibitive to use. RESOLUTION ========== New microcode, and possibly a new firmware image is required to prevent SMM data from being leaked with this vulnerability. Consult your hardware vendor. Software updates to Xen (details below) are required to prevent guests from being able to leak data belonging to Xen or to other guests in the system. Guest kernel software updates are required to prevent guest userspace from being able to leak data belonging to the kernel or other processes within the same guest. Consult your OS vendors. 1) For PV guests (which fall into the CVE-2018-3620 - OS/SMM case), leakage of data from Xen or other guests can be prevented entirely with software changes in Xen. If the PV guest tries to write an L1TF-vulnerable PTE (for current kernels, very likely when paging data out to disk), shadow paging is activated and forced upon the guest. Alternatively, if shadow paging is compiled out, the guest is crashed instead. Shadowing comes with a workload-dependent performance hit to the guest. Once the guest kernel software updates have been applied, a well behaved guest will not write vulnerable PTEs, and will therefore avoid the performance penalty (or crash) entirely. This behaviour is active by default for guests on affected hardware (controlled by `pv-l1tf=`), but is disabled by default for dom0. Dom0's exemption is because of instabilities when being shadowed, which are under investigation, but dom0 kernel updates should still be taken to mitigate the userspace aspect. 2) For HVM and PVH guests running with Hardware Assisted Paging (which fall into the CVE-2018-3646 - Hypervisors case), leakage of data from Xen or other guests can only be prevented entirely by disabling SMT/Hyper-threading (if available and active in the BIOS), and by using the L1D_FLUSH feature (available in the new microcode) on every VMEntry. On affected hardware, L1D_FLUSH is enabled by default (controlled by `spec-ctrl=[no-]l1d-flush`), subject to microcode availability. However, SMT/Hyper-threading is not disabled by default, because Xen does not have enough information to choose an appropriate default. Safety can be arranged in a number of ways by the toolstack, including with finer granularity than simply on or off. Therefore, users are expected to perform a risk assessment of their deployment, and explicitly chose a default (`smt=`). See the RISK ASSESSMENT section below. Xen will issue a warning at boot on vulnerable hardware when no explicit smt choice has been set. There are ongoing experimentation and development efforts to find lower overhead mitigations for the HVM case. We are not supplying separate patches because the changes have many complicated prerequisites. To get the fixes, it is necessary to update to the latest Xen applicable staging-XX branch. The relevant git commit object ids are as follows: d757c29ffe2e31b15397e43cd58da88b6318b654 staging-4.11 13e85a6dbc1eeda4f95c0d3afcd205579eab5909 staging-4.10 14f90aaef8d441cbdece5b74829e85e767fb196c staging-4.9 d95b5bb31e6d4361e356f0ff0853b6bb172a8b6a staging-4.8 9b8375a272ad02d8d0c229b3e3e7989e852734d8 staging-4.7 e1b03b03b199bd206c81286b4f51b6a681123eda staging-4.6 aa67b97ed34279c43a43d9ca46727b5746caa92e staging # xen-unstable In each case the tip commit is "xl.conf: Add global affinity masks". RISK ASSESSMENT OF SMT/HYPER-THREADING ====================================== 1) If hyper-threading is unavailable, or already disabled in the BIOS, no further action is necessary. 2) If you are using exclusively PV or HVM Shadow guests, hyper-threading has no impact on security, and is safe to remain enabled. 3) If an HVM guest kernel is trusted (i.e. under host admin control), and has been updated to include the OS vendor mitigations, then it is probably safe to be scheduled with hyper-threading active. 4) If an HVM guest kernel is untrusted (i.e. not under host admin control), it is probably not safe to be scheduled with hyper-threading active. FINER GRAINED SMT/HYPER-THREADING CONTROL WITH TOOLSTACK SETTINGS ================================================================= New options (vm.cpumask, vm.hvm.cpumask and vm.pv.cpumask) have been added in the xl/libxl toolstack to provide global control over CPU hard affinity settings. The global masks are applied when a guest is created or when a vcpu is pinned. Sketch of how to use the new options: 1. Livepatch the hypervisor. 2. Identify all sibling threads and partition them with the new options in xl.conf. 3. For each DomU, run `xl vcpu-pin $DOM all all`, which should cause the global masks to be applied to all vcpus of a DomU. 4. Verify the required affinity has taken effect by running `xl vcpu-list`. The default behaviour of xl is to always apply global masks unless `--ignore-global-affinity-masks` is specified. Please refer to xl.conf(5) for details. NOTE CONCERNING CVE-2018-3615 ============================= CVE-2018-3615 covers the interaction of L1TF and Intel SGX. Xen has no support for enclaves in any currently released version, so no Xen systems are affected. NOTE REGARDING LACK OF EMBARGO ============================== Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. _____________________________________________________________________ Xen Security Advisory CVE-2018-15470 / XSA-272 version 3 oxenstored does not apply quota-maxentity UPDATES IN VERSION 3 ==================== CVE assigned. ISSUE DESCRIPTION ================= The logic in oxenstored for handling writes depended on the order of evaluation of expressions making up a tuple. As indicated in section 7.7.3 "Operations on data structures" of the OCaml manual: http://caml.inria.fr/pub/docs/manual-ocaml/expr.html the order of evaluation of subexpressions is not specified. In practice, different implementations behave differently. IMPACT ====== oxenstored may not enforce the configured quota-maxentity. This allows a malicious or buggy guest to write as many xenstore entries as it wishes, causing unbounded memory usage in oxenstored. This can lead to a system-wide DoS. VULNERABLE SYSTEMS ================== Xen 4.1 and later are potentially vulnerable. Only systems using the OCaml xenstored implementation are potentially vulnerable. Systems using the C xenstored implementation are not vulnerable. Whether the compiled oxenstored binary is vulnerable depends on which compiler was used. OCaml can be compiled either as bytecode (with ocamlc) or as a native binary (with ocamlopt). The following OCaml program demonstrates the issue, and identifies whether the resulting oxenstored binary will skip the quota enforcement. $ cat order.ml let check () = let flag = ref false in let update _ = flag := true; () in List.iter update [1;2;3], !flag let main () = let _, flag = check () in if flag then print_endline "This code is not vulnerable!" else print_endline "This code is vulnerable!" let () = main () $ ocamlc order.ml -o order.bytecode $ ./order.bytecode This code is vulnerable! $ ocamlopt order.ml -o order.native $ ./order.native This code is not vulnerable! To confirm whether an OCaml binary is bytecode or native, use file. $ file order.bytecode order.bytecode: a /usr/bin/ocamlrun script executable (binary data) $ file order.native order.native: ELF 64-bit LSB executable, ... NOTE: These results are applicable to OCaml 4.01.0-5 as distributed in Debian Jessie. These results are not representative of other versions of OCaml, or of other OS distributions. MITIGATION ========== There are no mitigations available. CREDITS ======= This issue was discovered by Christian Lindig of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa272.patch All versions of Xen $ sha256sum xsa272* 0da953ca48d0cf0688ecff6a074304a9d2217871809a76ef26b9addeb66ecb3e xsa272.meta 6e0359d89bf65794f16d39198cc90f5c3137bce4eb850e54625ab00e2c568c2c xsa272.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-2018-14007 / XSA-271 version 2 XAPI HTTP directory traversal UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= XAPI has an unauthenticated HTTP endpoint update/ which exports the contents of /var/update for other hosts to use. However, the resolution of . and .. in paths is performed before url unquoting is performed. This allows an attacker to traverse out of the web root. IMPACT ====== An unauthenticated user with access to the management network can read arbitrary files from the dom0 filesystem. This includes the pool secret /etc/xensource/ptoken which grants the attacker full administrator access. VULNERABLE SYSTEMS ================== All versions of XAPI since v1.13.0 are vulnerable. If the directory /var/update doesn't exist, the vulnerability is not exposed. MITIGATION ========== In the recommended configuration, the management network is isolated and isn't reachable from untrusted hosts, or by general network traffic. CREDITS ======= This issue was discovered by Ronald Volgers of Computest https://www.computest.nl/en/ RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa271-xapi.patch $ sha256sum xsa271* ffefb71cd328e0ee5654c135bf9b08f48abedd013f1c68d5589132e2a03a01f8 xsa271-xapi.patch $ REGENERATION OF POOL SECRET =========================== There are no known exploits in the wild. If there is a risk that credentials could have been stolen, they should be reset. Most credentials can be reset via normal administrative means, but the pool secret doesn't have any mechanism to reset. The following instructions should be used: 1) On all pool members, stop Xapi: # service xapi stop 2) On the pool master: # rm /etc/xensource/ptoken # /opt/xensource/libexec/genptoken -f -o /etc/xensource/ptoken 3) Copy /etc/xensource/ptoken to all pool slaves 4) On the pool master, restart the toolstack: # xe-toolstack-restart 5) On all pool slaves, restart the toolstack: # xe-toolstack-restart Once the pool secret has been regenerated, the root password can be changed with: # xe user-password-change Furthermore, consideration should be given to other credentials, such as (but not limited to) SSL keys, Storage SAN/iSCSI/NFS details, as well as secrets contained within VMs disks/snapshots/etc. 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-2018-15471 / XSA-270 version 3 Linux netback driver OOB access in hash handling UPDATES IN VERSION 3 ==================== CVE assigned. ISSUE DESCRIPTION ================= Linux's netback driver allows frontends to control mapping of requests to request queues. When processing a request to set or change this mapping, some input validation was missing or flawed. IMPACT ====== A malicious or buggy frontend may cause the (usually privileged) backend to make out of bounds memory accesses, potentially resulting in one or more of privilege escalation, Denial of Service (DoS), or information leaks. VULNERABLE SYSTEMS ================== Linux kernel versions from 4.7 onwards are affected. MITIGATION ========== There is no known mitigation. CREDITS ======= This issue was discovered by Felix Wilhelm of Google Project Zero. RESOLUTION ========== Applying the attached patch resolves this issue. xsa270.patch Linux 4.7 ... 4.17 $ sha256sum xsa270* 392868c37c1fe0d16c36086208fd0fc045c1baf8ab9b207995bce72681cb8c54 xsa270.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-2018-15468 / XSA-269 version 3 x86: Incorrect MSR_DEBUGCTL handling lets guests enable BTS UPDATES IN VERSION 3 ==================== CVE assigned. ISSUE DESCRIPTION ================= The DEBUGCTL MSR contains several debugging features, some of which virtualise cleanly, but some do not. In particular, Branch Trace Store is not virtualised by the processor, and software has to be careful to configure it suitably not to lock up the core. As a result, it must only be available to fully trusted guests. Unfortunately, in the case that vPMU is disabled, all value checking was skipped, allowing the guest to chose any MSR_DEBUGCTL setting it likes. IMPACT ====== A malicious or buggy guest administrator can lock up the entire host, causing a Denial of Service. VULNERABLE SYSTEMS ================== Xen versions 4.6 and later are vulnerable. Only systems using Intel CPUs are affected. ARM and AMD systems are unaffected. Only x86 HVM or PVH guests can exploit the vulnerability. x86 PV guests cannot exploit the vulnerability. MITIGATION ========== Running only x86 PV guests avoids the vulnerability. CREDITS ======= This issue was discovered by Andrew Cooper of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa269.patch xen-unstable xsa269-4.11.patch Xen 4.11 xsa269-4.10.patch 4.10, 4.9 xsa269-4.8.patch Xen 4.8, 4.7, 4.6 $ sha256sum xsa269* 4733d09bb63523744ca2ee172e2fade0c39082c15d9a746144f279cf1359b723 xsa269.meta 5a5fe36f1f876a5029493e7fa191436fd021929aaba2d820636df17f4ed20113 xsa269.patch ea11cef818050bca13d4eb89294627c97e4cdb830124f679e77d37a44a370286 xsa269-4.8.patch 45ba1823530f329dd73088b77098e686b32f5daac0bc5177b2afea09f8c3593a xsa269-4.10.patch e0ca060311fb9ba3247e2fe65bca4806a131644f8894fd08be374904904b1944 xsa269-4.11.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-2018-15469 / XSA-268 version 3 Use of v2 grant tables may cause crash on ARM UPDATES IN VERSION 3 ==================== CVE assigned. ISSUE DESCRIPTION ================= ARM never properly implemented grant table v2, either in the hypervisor or in Linux. Unfortunately, an ARM guest can still request v2 grant tables; they will simply not be properly set up, resulting in subsequent grant-related hypercalls hitting BUG() checks. IMPACT ====== An unprivileged guest can cause a BUG() check in the hypervisor, resulting in a denial-of-service. VULNERABLE SYSTEMS ================== Only ARM systems are vulnerable. All supported versions of Xen are vulnerable. MITIGATION ========== None. CREDITS ======= This issue was discovered by 王磊 of Samsung. RESOLUTION ========== Applying the appropriate attached patch resolves this issue by preventing a guest from switching to grant v2. xsa268.patch xen-unstable xsa268-4.11.patch Xen 4.11.0 xsa268-4.10-?.patch Xen 4.10.x xsa268-4.9-?.patch Xen 4.9.x, Xen 4.8.x xsa268-4.7-?.patch Xen 4.7.x xsa268-4.6-?.patch Xen 4.6.x $ sha256sum xsa268* f336b45676e73f8b102e5dddf78af2d1d288f9a254142a8a8e9949db55e1cc3b xsa268.meta ca5f69cb8cfb74fae44a0f39f80ec9ae4d269c4895f36311b50d191be97bbcf0 xsa268.patch 93a68a5b23aedc6adf0aae23303dc8eb2c02dc40a5e1d7eb0a1b497cd66da209 xsa268-4.6-1.patch 5b74afd13d96779a72dc34ba7c63a1735cd267fb9bb643f735ac69b0e6ff54d5 xsa268-4.6-2.patch 820e1018f76ef2828b1cbb33e2966b99f6934a80ab55f11749ff847d375d1b02 xsa268-4.7-1.patch 233f7e69e5fb931d2e5cf03f4407f38ff960c039c9eced957df13d3cc37fa6b1 xsa268-4.7-2.patch 4a0c705f0266185b32daf313e686abc340e2fbb1a1644647500fc405bc180913 xsa268-4.9-1.patch ce16eaab94cd1e64f9c9127b64da7ebb6a7758eb540fecc3bbcc2dbfbcc4d7e2 xsa268-4.9-2.patch f413d41fadefe0e275c8bff16a2061bb325f3900b7ccf214a9e97fabf3ee1a89 xsa268-4.10-1.patch 531654f82908c1aa7b0fcea818c82c4b53d4750a697db3353cc05e9e91e5d639 xsa268-4.10-2.patch baeb6b2c28a9cbe929c9cf34398780002fffe12b928df4d1e5951c0a5b51336a xsa268-4.11.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 + =========================================================