Meltdown & Spectre Attacks and Mitigations

Baidu X-Lab comprehensively investigates Meltdown & Spectre Attacks and Mitigations.

1. Introduction

Recently, Google Project Zero and some security researchers independently identified some very serious CPU bugs in out-of-order execution and speculative execution, which is able to leveraged by adversaries to leak private data via cache-based side channel techniques. These exploits are known as Meltdown [4] and Spectre [5]. The variants of Spectre are related to CVE-2017–5753 (bounds check bypass) and CVE-2017–5715 (branch target injection)，while Meltdown refers to CVE-2017–5754 (rogue data cache load).

The root cause of Meltdown and Spectre attacks are processor hardware bugs, and thus all popular CPUs, OSes and VMMs on cloud platforms and personal computers in the recent 20 years are vulnerable to both attacks. Through these two attacks, the adversary is able to leak confidential data and private information, such as encryption key, password, and private tokens, and even dump the whole kernel image. Fortunately, both of them can only steal data, rather than tampering with data. The affected CPU processors, OSes and VMMs are listed as follows:

• CPU Processors: All Intel, AMD, ARM in the recent 20 years are affected，especialy to Intel processors；
• Operating systems: Windows、Linux、 Android、iOS and macOS etc；
• VMMs：KVM, Xen etc.

In this document, we focus on the Intel CPU Meltdown and Spectre attacks and mitigations, including VMM and browser scenarios. We believe that these observations, discussions and mitigation suggestions will help people who work on the ARM/AMD platforms. The impacts of Meltdown and Spectre attacks are broad, but the exploits on the real platform are not that simple as claimed. There are many restrictions in reality and we will talk about this later. We hope that through this document, we can help people to alleviate the scare currently exaggerated by the media. In this document, we also discuss some possible solutions (some of them are already documented by others, while some are not). Companies and individuals could choose the best one/combination according to the cost and the application scenarios. In addition, we will report some attack variants experimentally approved by our group. It seems that these variants are more powerful than the regular ones. Thus, we cannot treat these attacks lightly, and need to take action quickly.

2. Attack Scenarios

There are three variants of Meltdown [4] and Spectre [5] attacks:

• Variant 1 (V1) Spectre: Bounds check bypass (CVE-2017–5753)
• Variant 2 (V2) Spectre: branch target injection (CVE-2017–5715)
• Variant 3 (V3) Meltdown: rogue data cache load (CVE-2017–5754)

Due to the diversity of the affected Cloud platforms and Operating Systems, we do not explicitly enumerate the specific mitigation for each of them, instead, we’d like to present the solutions for each typical attack scenarios.

Typical Attack Scenarios

1. Attack to VMM (A1): The adversary could be in one of VMs managed by the target VMM, and she is able to completely control the VM, e.g., she can run arbitrary instructions with the VM kernel privilege, and trigger event or launch hypercalls to directly communicate with VMM. The purpose of the adversary is to leak the secret data of VMM or other VMs on the same physical machine;
2. Attack to OS (A2): The adversary is one of the user applications, and she is able to issue any instructions allowed by userspace. The purpose of the adversary is to gain kernel secret data, including the file in the page cache and data in the network stack.
3. Attack from browser to OS (A2w): The adversary can only launch the attack through one or more web pages, e.g., leveraging JavaScript or web assembly;
4. Attack to Applications (including those in docker) (A3): The adversary is one of the user application and can issue any instructions allowed by userspace. The purpose of the adversary is to leak the credential data of other processes, including the ones in docker;
5. Attack from a browser to an application (A3w): The adversary can only launch the attack through one or more web pages, e.g., leveraging JavaScript or web assembly.

V3c Composition Attack

The original V3 attack inevitably introduces page faults, which are easily captured by the kernel and the host instruction detection system (HIDS). One of a solution is to use Intel Transactional Synchronization Extensions (TSX) mechanism to intercept the page fault, hiding them to OS and HIDS. However, due to the TSX bugs, most of the cloud machines are recommended to disable TSX, leading to the unavailability of the TSX mechanism on these machines.

According to our experiments, putting V3 into the speculative execution of V1/V2, there is no page fault at all. This attack is named as V3c attack or V1/V2->V3. The V3c is as powerful as V3, but has no page fault side effect. To mitigate the V3c attack in the A2 scenario, KPTI patch is necessary.

3. Defence and Mitigations

We summarize all attack scenarios and mitigations (in Table 1). Note that in the cloud setting, upgrading CPU microcode would need the assistance of VMM. Users in VM cannot do this unless VMM enable this feature to VM.

Table 1：Mitigation summary for different attack scenarios. “NO*” means that the adversary cannot directly to attack other processes, but she can indirectly attack them via kernel (A2). “A” means “Attack”, while “M” means “Mitigations”

Each mitigation solution has its own security gains and different deployment and performance costs, and thus we suggest to choose the solutions that balance the cost and security gains.

For public cloud providers, they should ensure that the VMMs are well protected, against any attacks (especially to V2 attack) under A1 setting. The cloud with Xen as the VMM should also take care of V3 attack.

Tenants on the cloud also need to harden their VMs. For A2.V3, it will introduce non-negligible performance overhead and thus tenants should evaluate both the risk of data leakage and the performance loss according to their own application scenarios. According to our evaluations on the V3 attack, it is extremely hard to leak arbitrary kernel address. Thus, we suggest the tenants that have strong requirements on performance and weak requirements on data secrecy could still work on the original kernel. However, if the tenants have highly sensitive data in multiple layers, they should apply the V3 patch.

For individuals working on PC, their main threats are from browser due to the visiting of malicious/vulnerable web pages. Please follow our suggestion summarized in Table 1 to upgrade your system and browsers.

4. Attack Analysis

1）Spectre Attack

There are two variants for Spectre attack. The first variant (V1) is Bounds Check Bypass attack, and the second variant (V2) is Branch Target Injection attack.

As of 2018, almost every computer system is affected by Spectre, including desktops, laptops, and mobile devices. Specifically, Spectre has been shown to work on Intel, AMD, and ARM-based processors [8, 2]. Intel responded to the reported security vulnerabilities with an official statement. According to a statement by AMD, vulnerability to the second Spectre variant hadn’t been demonstrated on AMD processors and posed ”near zero risk of exploitation” due to differences in AMD architecture [1].

Bounds Check Bypass — V1

The V1 attack is able to bypass memory bound checking. The main reason is that CPU speculatively executes the instructions after conditional branch instructions. The time of the speculative execution may have dozens of CPU cycles. Although the registers and memory do not have any side effect after the speculative execution fails, the CPU cache will have certain fingerprint about the memory access and the adversary is able to discover the content of the victim buffer through some sophisticated side-channel techniques. In short, there are two requirements for launching a V1 attack, 1) the adversary has to be able to discover the V1 gadget code, and 2) the offset (x in Figure 1) should be provided/controlled by the adversary. One example gadget is listed in Figure 1.

Figure 1：A typical V1 gadget. Note that x is provided/controlled by the adversary, otherwise, this gadget cannot be used in a V1 attack.

If the attacker can identify an appropriate gadget in a more privileged level, the attacker may be able to exploit that. Fortunately, such gadgets are not popular.

Branch Target Injection — V2

The branch target injection method takes advantage of the indirect branch predictors inside the processor that are used to direct what operations are speculatively executed. There are many methods for the adversary to manipulate the indirect branch predictors, e.g., through RSB and BTB, the adversary is able to make the processor to speculatively execute the selected instruction sequence (gadget) starting from the expected address.

There are two types of branch instructions: conditional direct branch and indirect branches.

For conditional direct branches, there are only two options: (1) the target of the branch, and (2) the fall-through path of instructions directly subsequent to the branch. it is impossible for the adversary to cause the code to execute beyond these two locations.

For indirect branches, they allow many targets for speculative execution. The selected gadget could create a cache-based side channel based on the value of the sensitive data (e.g., private key, token). Due to the diversity of the types of the processors and the mechanisms of the indirect branch predictors, V2 attack will be case by case. In addition, the hyperthreading also increases the complexity of V2 attacks and even mitigations.

About ASLR

To launch a V2 exploit, the adversary has to know the location of the target indirect branch before preparing the malicious indirect branches. While, on the other hand, we know that the ASLR mechanism is able to hide the location of the code. It seems that ASLR is one of the perfect solutions to mitigate the V2 attack. However, in reality, there are serious information leakage issues for ASLR, and therefore the adversary is able to bypass the ASLR mechanism to exactly locate the target indirect branch, and consequently launch a V2 attack. To effectively mitigate V2, a hardened and fine-grained ASLR is expected.

Memory Latency in Speculative Execution

The time of the speculative execution is quite short, e.g., there are only dozens of CPU cycles for a V1 attack. Thus, if the target memory is not cached in CPU cache, it will spend hundreds of CPUs for the processor to bring it into the cache, which inevitably leads to the failure of the attack due to the time out.

To address the above challenges, one possible solution for the adversary is to trigger the memory load event multiple times and hope that the processor is able to put the data into cache after certain rounds. We tested this new solution, unfortunately, the result indicates that this attempt does not work. This observation also implies that all existing PoCs do not have the capability to read arbitrary kernel memory. The attack is not that powerful as described by the media.

2）Meltdown Attack — V3

This method allows a (user) application to directly probe kernel (supervisor) memory. In the normal cases, such an operation would typically result in a program crash due to the page fault triggered by permission checking. However, it is possible for such an operation to be speculatively executed under certain conditions. For instance, on some architectures, such a speculative operation will pass data on to the subsequent operations when the data is resident in the L1D cache. This can allow the target data to be queried by the application, leading to a side channel that reveals kernel data. This method only applies to regions of memory mapped by the page tables. The memory regions are safe if they are not mapped by page tables (not present).

The Meltdown vulnerability primarily affects Intel microprocessors. It is thought not to affect AMD microprocessors. Intel has countered that the flaws affect all processors, but AMD has denied this, claiming that there is near zero chance for their processors to be affected [7]. ARM has reported that the majority of their processors are not vulnerable, and published a list of the specific processors that are affected. However, the ARM Cortex-A75 core is affected directly by the Meltdown vulnerability, and cores Cortex- A15, Cortex-A57, and Cortex-A72 are affected by variations of the Meltdown vulnerability [7]. Also, all Raspberry Pi computers are not vulnerable to either Meltdown or Spectre [6].

Figure 2：The core operations of the Meltdown attack

3）Browser-based Attacks

Technically, the attacker has the ability to launch Meltdown and Spectre attacks in web browsers via malicious JavaScript/WebAssembly scripts. However, such attacks can barely do harm to the system, due to the strict restriction of the script engines.

The first challenge is ASLR bypassing. As we discussed above, both V1 and V2 attack depend on the precise address of certain code gadgets. But modern browsers have fine-grained ASLR for exploit mitigation. To bypass ASLR, Fengshui based exploitation might be effective along with some brute forcing methods in Meltdown and Spectre attacks. But we haven’t found any scripts which can effectively and effectively conduct such attacks to escape from a sandbox.

We have successfully tested V1 PoC (similar to [12]) in Chrome 63.0.3239.84. The experiment proves that it is possible to steal data across sites in the browser. But in the real world, it is extremely hard for the adversary to get an expected gadget and the exact location of the secret. In short, it is pretty much challenging to launch a V1 attack in web browsers.

As of Meltdown, the attacker cannot directly launch such attacks due to the strong boundary check mechanism enforced by the script engine. At the first glance, it seems possible to combine V1 and V3 attacks to V3c, a combination attack. However, V3c is almost impossible because of ASLR. Thus the attacker needs an additional information leakage vulnerability to collect the address information or has to take a long time to scan the memory for secrets. In addition, the Array index of JavaScript is typed as Uint32 [11], which makes it impossible to access kernel memory address via a single element access on the popular x64 platforms. WebAssembly, especially wasm64 (64-bit version of WebAssembly), provides memory accessibility of the whole 64-bit memory space, but it is still hard for launching Meltdown because of the lack of threading mechanism and the low-resolution timer.

5. Mitigation Solutions

Bounds Check Bypass Mitigation — V1 Mitigation

The Bounds Check Bypass attack highly relies on the V1 gadget. Thus, the promising software mitigation is to insert a barrier to stop speculation in the V1 gadget. In particular, the use of an LFENCE instruction is recommended for this purpose. Note that MFENCE also work here but it has higher performance loss.

Figure 3：V1 Mitigation. Adding LFENCE instruction right after bound check statement, preventing the speculative execution.

Note that on Linux adversaries are able to inject V1 gadget into kernel space through eBPF interface, making the bounds check bypass attack easier. Thus, disabling eBPF mechanism would be a promising way to quickly increase the bar for launching the bounds check bypass attack. According to one Intel’s report [3], there are only limited suspicious V1 gadgets in the Linux kernel. Thus, the possibility for a V1 attacker to launch a meaningful exploit on Linux would be very small.

Branch Target Injection Mitigation — V2 Mitigation

For the branch target injection attack, two mitigation techniques have been developed.

RSB Padding + BTB Flushing. This is a software-only mitigation solution. The core idea is to eliminate all suspicious buffer (i.e., RSB and BTB), invalidating all possible injected branches. Due to RSB is a circle buffer with limited size (e.g., 32 slots), and thus it is possible to pad it with fake calls. Figure 4 is a working patch for RSB padding. BTB is a mapping table with 1K to 16K entries. There is index function f(x) translating virtual address v_addr to BTB index (B_i) (see Figure 5). Unfortunately, Intel does not disclose the details of f(x), and thus it needs some reverse engineering efforts here. Similar to RSB padding, we need enough fake branches to flush all BTB entries, like Figure 5. Note that this mitigation solution may introduce high-performance overhead.

Figure 4：RSB Padding. Need 32 fake calls to padding RSB.

Figure 5：BTB Flushing. Need 1K to 16K to flush the whole BTB.

Microcode Upgrade + System software（VMM/kernel) Patches. This mitigation strategy requires both system software update and a microcode update to be loaded to support the new interface for many existing processors. This new interface will also be supported on future Intel processors. There are three new capabilities that will now be supported for this mitigation strategy. These capabilities will be available on modern existing products if the appropriate microcode update is applied, as well as on future products, where the performance cost of these mitigations will be improved.

In particular, the capabilities are:

1. Indirect Branch Restricted Speculation (IBRS). If IBRS is set, near returns and near indirect jumps/calls will not allow their predicted target address to be controlled by code that executed in a less privileged prediction mode before the IBRS mode was last written with a value of 1 or on another logical processor so long as all RSB entries from the previous less privileged prediction mode are overwritten.
2. Single Thread Indirect Branch Predictors (STIBP). Prevents indirect branch predictions from being controlled by the sibling Hyperthread.
3. Indirect Branch Predictor Barrier (IBPB). The setting of IBPB ensures that earlier code’s behaviour does not control later indirect branch predictions. It is used when context switching to a new untrusted address space.

To test whether a CPU is supporting this feature, we can use CPUID with ax=0x7, The return rdx bit 26 to indicate the presence of this feature. Please refer to KVM and Linux kernel patches to get the latest patches.

If you cannot upgrade microcode for certain reasons, please consider Retpoline technique [10] to replace all suspicious indirect call and jump branch instructions, mitigating V2 attacks.

In addition, similar to V1, disable eBPF on Linux is a fast way to increase the bar for launching V2 attacks.

Meltdown Mitigation — V3 Mitigation

The most promising mitigation approach for meltdown attack is KAISER or called KPTI. KAISER/KPTI ensures that privileged pages are not mapped when executing user code in order to protect against user mode access to privileged pages. The OS establishes two paging structure roots (CR3 values) for each user process. Note that KAISER/KPTI was originally proposed as a mitigation for side-channel attacks on Kernel Address Space Layout Randomization (KASLR) in the KASLR is Dead: Long Live KASLR paper.

KAISER/KPTI may introduce high-performance overhead for certain applications due to the TLB flushes caused by frequent reloading of CR3 during user-and-supervisor mode transitions. To reduce the performance overhead, an OS could take advantage of the Process Context Identifier (PCID) feature to reduce the frequency of TLB flushes.

6. Conclusions

In this document, we summarized the Meltdown and Spectre attacks and discussed some possible mitigation solutions. Companies and individuals could choose the best one/combination according to the cost and the application scenarios. In addition, we reported some new attack variants experimentally approved by our group. All these lessons told us that we cannot treat these attacks lightly, and need to take action quickly. We will continue updating it when we get new results.

Authors: Yueqiang Cheng, Yulong Zhang, Yu Ding, Tao Wei

Baidu X-Lab, Jan 8, 2018

Reference

1. AMD. An update on AMD processor security. 2018.
2. Douglas Busvine and Stephen Nellis. Security flaws put virtually all phones, computers at risk. 2018.
3. Intel. Intel analysis of speculative execution side channels. 2018.
4. Lipp Moritz, Michaelm Schwarz, Gruss Daniel, Prescher Thomas, Haas Werner, Mangard Stefan, Kocher Paul, Genkin Daniel, and Hamburg Yuval, Yarom Mike. Meltdown. 2017.
5. Kocher1 Paul, Genkin Daniel, Gruss Daniel, Haas Werner, Hamburg Mike, Lipp Moritz, Mangard Stefan, Prescher Thomas, Schwarz Michael, and Yarom Yuval. Spectre attacks: Exploiting speculative execution. 2017.
6. Raspberrypi. Why raspberry pi isn’t vulnerable to spec-
7. Spectre or meltdown. https://www.raspberrypi.org/blog/ why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/.
8. Wikipedia. Meltdown (security vulnerability). 2018.
9. Wikipedia. Spectre (security vulnerability). 2018.
10. Retpoline: a software construct for preventing branch-target-injection. https://support.google.com/faqs/answer/7625886
11. Standard ECMA-262, ECMAScript® 2017 Language Specification, https://www.ecma-international.org/ecma-262/8.0/index.html#sec-array-exotic-objects
12. Meltdown & Spectre risk assessment by Tencent Xuanwu lab, http://xlab.tencent.com/special/spectre/spectre_check.html