Date: Fri, 12 Jan 2018 12:15:59 +0000 From: Xen.org security team <security@....org> To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org, xen-users@...ts.xen.org, oss-security@...ts.openwall.com CC: Xen.org security team <security-team-members@....org> Subject: Xen Security Advisory 254 (CVE-2017-5753,CVE-2017-5715,CVE-2017-5754) - Information leak via side effects of speculative execution -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 5 Information leak via side effects of speculative execution UPDATES IN VERSION 5 ==================== PV-in-PVH/HVM shim approach leaves *guest* vulnerable to Meltdown attacks from its unprivileged users, even if the guest has KPTI patches. That is, guest userspace can use Meltdown to read all memory in the same guest. In Vixen shim sidecar creator script, look for qemu in some more places, and provide a command line option to specify the qemu-system-i386 to use in case the default doesn't find it. ISSUE DESCRIPTION ================= Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT ====== Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing arbitrary pre-existing code inside of Xen. For SP3 (and other cases for SP2), an attacker can write arbitrary code to speculatively execute. Additionally, in general, attacks within a guest (from guest user to guest kernel) will be the same as on real hardware. Consult your operating system provider for more information. NOTE ON TIMING ============== This vulnerability was originally scheduled to be made public on 9 January. It was accelerated at the request of the discloser due to one of the issues being made public. VULNERABLE SYSTEMS ================== Systems running all versions of Xen are affected. For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of ARM processors to SP1 and SP2 varies by model and manufacturer. ARM has information on affected models on the following website: https://developer.arm.com/support/security-update For SP3, only Intel processors are vulnerable. (The hypervisor cannot be attacked using SP3 on any ARM processors, even those that are listed as affected by SP3.) Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH, HVM, and 32-bit PV guests cannot exploit SP3. MITIGATION ========== There is no mitigation for SP1 and SP2. SP3 can be mitigated by running guests in HVM or PVH mode. (Within-guest attacks are still possible unless the guest OS has also been updated with an SP3 mitigation series such as KPTI/Kaiser.) For guests with legacy PV kernels which cannot be run in HVM or PVH mode directly, we have developed two "shim" hypervisors that allow PV guests to run in HVM mode or PVH mode. This prevents attacks on the host, but it leaves the guest vulnerable to Meltdown attacks by its own unprivileged processes, even if the guest OS has KPTI or similar Meltdown mitigation. The HVM shim (codenamed "Vixen") is available now. We expect to have the PVH shim (codenamed "Comet") available within a few days. Please read README.which-shim to determine which shim is suitable for you. $ sha256sum xsa254*/* 2df6b811ec7a377a9cc717f7a8ed497f3a90928c21cba81182eb4a802e32ecd7 xsa254/README.vixen 4c30295513ad82debe04845248b5baac0b3d0c151b80fdca32f2df8b9aa0b541 xsa254/README.which-shim 6210615c1384e13da953452e6f47066f8837e2b2c7f671280902e32e96763b54 xsa254/pvshim-converter.pl $ RESOLUTION ========== There is no available resolution for SP1. A solution may be available in the future. We are working on patches which mitigate SP2 but these are not currently available. Given that the vulnerabilities are now public, these will be developed and published in public, initially via xen-devel. NOTE ON LACK OF EMBARGO ======================= The timetable and process were set by the discloser. After the intensive initial response period for these vulnerabilities is over, we will prepare and publish a full timeline, as we have done in a handful of other cases of significant public interest where we saw opportunities for process improvement. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJaWKbzAAoJEIP+FMlX6CvZtl4H/RKmXpS1fL51efZbrhYaDBTF nLSHxfPdmi+MLaJ8Y7hS9w061ovK7OYTcvi9xlAhE6yC0b4lX5NToc1CPkX6pjGV atOh0q4QyxDQm9JGW1aL9pZa3ZSF/Y7ad/zv5OlU97ZmDEwuEVvOTSsGj+jMFB08 gJ+VfQ0F2R+sjdh9BIScbUedLEz+M5so2wGaOJObr/ybRfLyAobxwiIc+yPniBoi c4eNLSdzBjmg0YrRGeMToVziNH6YXmHD+VLSj23SbVYOjgSS/vnbpRtw7DbcwGXy jhwK8WheInGUsCe+Nz0VU54MXtRhkV+JtsB/g2h4flr49mUm8kt2VY3P0NO7dcE= =jGQH -----END PGP SIGNATURE----- Download attachment "xsa254/README.vixen" of type "application/octet-stream" (2499 bytes) Download attachment "xsa254/README.which-shim" of type "application/octet-stream" (3949 bytes) Download attachment "xsa254/pvshim-converter.pl" of type "application/octet-stream" (6701 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.