Wednesday, November 21, 2018

L1 Terminal Fault Vulnerability (L1TF) aka Foreshadow

L1TF Introduction

L1 Terminal Fault (L1TF) is a side-channel vulnerability in the Intel CPUs. This is another speculative execution vulnerability similar to the other ones that have been identified and disclosed in recent months (remember Spectre ?). Later on this vulnerability has been dubbed as Foreshadow.

Modern CPUs have up to 3 levels of cache. L1 cache is the smallest/fastest of them. Each CPU cache has its own L1 cache (while L3 is a larger one, shared by all cores, which leads to other issues and vulnerabilities classes). 

The key reason why such vulnerabilities exist is the speculative (or out of order) code execution. My coffee shop at work has this vulnerability. When a barista sees me in the morning she starts making a small latte BEFORE I even have an opportunity to place and order and pay. They know me so well that they PREDICT that I will be ordering a small latte. They are usually right, so it helps with the overall speed of delivery, which makes me a happy customer. If one day I decide to "troll" them and order something else they will have to discard the cup of small latte and start preparing a new order from scratch.

in the L1TF case the issue is caused by "over-optimization" in the CPU internal logic, when a virtual address translation happens in parallel with cache access to the L1 cache. I highlighted "in parallel" because while one process within CPU still tries to retrieve/figure out the bits related to the present/not present status of a particular Page Table Entry (PTE), the other process "hopes for the best" and assumes that the data/bytes that we are trying to read from that Page do already exist in cache. There are 2 different outcomes. In one case, the page is actually present in memory and the L1 cache contains the same value. This certainly helps with the overall performance since speculative execution has already used this value and moved execution forward. But in another case the needed page will not be in memory (e.g. swapped out to disk). In this case, a "terminal fault" condition will arise (hence the name for this class of vulnerabilities). Once the terminal fault/page not present condition happens the other process (that accessed data from L1 cache) has already progressed and accessed/used data values related to that memory page. An attacker can access/read data from physical addresses if a "not present" page table entry can be created for the addresses the attacker is interested in and if these addresses are present in the L1 cache.

By exploiting this type of vulnerability an attacker can extract various secrets stored in memory - passwords, crypto keys etc - i.e. being able to read privileged data across trust boundaries

Here is the original Intel article that describes the L1TF vulnerability:

L1TF vulnerability affects several generations of the Intel CPUs and has 3 CVEs associated with it with the first one carrying a high risk score of 7.3:

CVE-2018-3615 - L1 Terminal Fault: SGX
CVE-2018-3620 - L1 Terminal Fault: OS/SMM
CVE-2018-3646 - L1 Terminal Fault: VMM

Vulnerabilities of this kind affect multiple different companies, so it becomes hard to keep track of various advisories issued by these companies.

In this article I decided to collate knowledge base articles and remediation steps published by various affected vendors - all on one page.

Here is a nice "Spectre Meltdown checker" shell script that can check the status of various vulnerabilities in this family and the mitigation status:

3rd party advisories and mitigation guidance

Cloud hosting providers

Microsoft Azure
Google Cloud GCP
Digital Ocean

OEM, hardware vendors, software companies

Microsoft Server and Hyper-V
Considerations for OpenStack
VMWare and
VMWare performance impact

Now that we've covered the L1TF vulnerabilities, I have to mention that security research doesn't stop there. Just recently there were 7 (!) new Spectre and Meltdown-like variants published in this article. So there are new waves of patches coming our way ;)

No comments:

Post a Comment