New Meltdown Variant and its Mitigations

We identified a new Meltdown Variant that is able to reliably leak kernel memory. In addition, we proposed several defence schemes to mitigate this attack.

1. Introduction

In our previous reports [1][2], we introduced the basic attack mechanisms of Meltdown/Spectre and their mitigations on Intel and ARM platforms. In this report, we focus on a new Meltdown variant discovered by our team and the possible mitigations. For the traditional Meltdown (or called V3) attack, it allows a process (A) to dump/read the kernel data (D). However, this attack has an extremely strong requirement: the target data should be in the L1D cache. If the target data is not in L1D cache (even it is in L2 or L3 cache), the process (A) has no chance to get the target data (D) through V3. It is concluded that V3 attack has no capability to read arbitrary kernel data. Fortunately, the newly identified Meltdown attack, named as V3r, fixes this gap, which allows an unprivileged process to reliably read arbitrary kernel data, no matter if the target data is in L1D cache or not. In the last part of this report, we will discuss the possible mitigations.

2. New Meltdown Variant

2.1 Meltdown Retrospection

2.1.1 Traditional V3 Attack

The traditional V3 attack (known as Meltdown attack) is able to allow an unprivileged process to read kernel data that should be in the L1D cache. Specifically, the access to kernel space from user space will inevitably trigger an exception (i.e., page fault exception) due to the privilege checking by MMU. In this situation, CPU will stop to execute the following instructions and switch to the exception handler. However, due to the out-of-order execution, there is a small timing window to execute some instructions before the CPU switches to the exception handler. These instructions executed in an out-of-order way could have some side effects on CPU cache, e.g., load certain data into cache dependent on the value of the target kernel data. As a result, an unprivileged process could read indirectly get the data through a cache-based side channel. A typical code sample of V3 is shown in Figure 1.

Figure 1：A typical code sample of traditional Meltdown (V3)

2.1.2 V3c Attack

One limitation of the traditional V3 attack is that it would trigger a page-fault exception, which could be easily detected by system software or any IDS/IPS software. One possible solution to hide the #PF exception is using Intel Transactional Synchronization Extensions (TSX) to intercept it. The TSX allows a process to intercept the #PF exception before the kernel is aware of it. Unfortunately, the Intel TSX is widely disabled on Cloud servers due to the known TSX bugs, and thus this solution is not generic.

Another promising solution identified by our team is to put a V3 gadget in the speculative execution path of V1/V2. Due to the mechanism of the speculative execution, there is no #PF execution triggered, which is proved by our experiments. We name this combination attack (V1/V2->V3) as V3c.

2.1.3 Summary of V3/V3c Attacks

Based on our analysis and experiments, we summarize some interesting observations related to V3 and V3c as follows:

1. If there is NO address mapping in the page table to the target data, V3/V3c will fail;
2. If there is address mapping in the page table but the target data is NOT cached in L1D, V3/V3c will fail. The situations where data is NOT in L1D include:

(a). data is in the main memory, or

(b). data is in the L2/L3 cache

3. If there is address mapping in the page table but the target data is cached in L1D, V3/V3c will succeed.

In many public V3 PoC demos, they demonstrated that an unprivileged process is able to dump the content of the sys_call_table. The reason is that system calls are frequently used, and thus the corresponding slots of the sys_call_table are likely cached in L1D, resulting in the success of V3. If they randomly choose some kernel addresses to read, the demos will fail (according to our experiments).

2.2 New Meltdown Variant (V3r)

To address the limitations of V3 and V3c that cannot reliably read arbitrary kernel data, we propose a new Meltdown variant, named as V3r, which is able to reliably read any kernel data. Specifically, there are two main steps for V3r:

1. Load kernel data. An unprivileged process leverage kernel interfaces, such as system calls, to trigger the expected speculative execution (e.g., similar to the out-of-bounds behaviour of V1) to load the target kernel data into the L1D cache.
2. Launch V3/V3c attack. The unprivileged process launches a V3 or V3c attack, read the target kernel data cached in L1D.

2.2.1 Load Kernel Data Via Speculative Execution

Due to the security and privacy concerns, all the mainstream kernels do not allow any unprivileged or privileged processes to read/load kernel data. Thus, we need some special method to achieve this goal. In our current PoC, we choose speculative execution. To understand the details of speculative execution, please refer to our previous reports [1][2].

The idea is inspired by V1 gadget, but it should not have the limitation of V1 gadget (i.e., require two array access, and the first one should be out-of-boundary). Specifically, our V3r gadget for the first step only requires one out-of-boundary access. Through this gadget, we can achieve the following two goals: (1) the target kernel data will be loaded into the L1D cache; and (2) the corresponding address mapping to the target kernel address will be cached in TLB. Through the 2nd achievement (i.e., cached addressing mapping in TLB), it allows an unprivileged process to reuse the cached addressing mapping in TLB, without needing additional page table walking. This gives a chance to access the target kernel address even if there are two isolated/separated page tables. The sample V3r gadget is shown in Figure 2. It is very common and there should be lots of code samples with a similar pattern, which provides a high possibility for the adversary to launch the V3r attack.

Figure 2：A typical gadget for a V3r attack. Note that the variable x should be controlled by the adversary.

We have tested our PoC on Linux 4.4.0 with Intel CPU E3–1280 v6 and MacOS 10.12.6 (16G1036) with Intel CPU i7–4870HQ. The experiment results indicate that V3r allows an unprivileged process to read arbitrary kernel data.

3. V3r Mitigations

Now the only known mitigation solution for V3 is KPTI (kernel page table isolation). With the help of PCID/ASID, KPTI could mitigate V3 attack with less performance overhead.

A carefully configured KPTI is still an effective mitigation solution for V3r. In a V3r attack, we found that PCID/ASID is able to provide not only performance improvement but also have security enhancement. In the legacy systems without PCID/ASIS support, they are likely to be attacked by the V3r attack (see Table 1). Specifically, the address mappings to kernel space are usually set as Global (G bit set) [3]. If these mappings are still kept in KPTI solution, the system will vulnerable to V3r attack.

Table 1：Attack and Mitigation Analysis of V3 and V3r. Note that Effective Mitigation* is: the mitigation is ineffective when the corresponding address mapping is still in TLB; the mitigation is effective for all other cases, including hyperthreading environment.

Based on the summarizations in Table 1, we can easily find out that V3r is more powerful and has a higher requirement for mitigation solutions. If the kernel page table is not properly configured (i.e., the Global bit is still set), the corresponding kernel data will be vulnerable to V3r attack.

4. Conclusions

In this report, we summarized all exiting Meltdown attacks and described a new Meltdown variant V3r identified by our team. All existing Meltdown attacks (V3 and V3c) could only read the kernel data in the L1D cache, while our newly discovered V3r could reliably read any kernel data. According to our experiments, V3r required stronger mitigation approach. If the kernel addresses are still mapped as global as before, all the data on these kernel addresses are vulnerable to V3r. It implied that the V3 variants ware more powerful than we think before, and thus we urged the related organizations and all Cloud providers to apply the corresponding patches ASAP.

Authors: Yueqiang Cheng, Zhaofeng Chen, Yulong Zhang, Tao Wei.

Baidu USA X-Lab

Reference

1. Meltdown & Spectre Attacks and Mitigations (1) https://bsi.baidu.com/article/detail/99
2. Meltdown & Spectre Attacks and Mitigations (2) https://mp.weixin.qq.com/s/7kAK5agn09f-l7IKhxt3Jg
3. Paging https://wiki.osdev.org/Paging