Foreshadow: harbinger of trouble?

    The current 2018 is interesting because almost every month there is information about new hardware vulnerabilities: Specter and Meltdown .

    Just recently - a couple of weeks ago! - Loud news about Foreshadow and L1Terminal Fault vulnerabilities was published , which, as reported, can even bypass the SGX (Sofware Guard Extensions) mechanism , previously considered practically unbreakable.

    How dangerous are these vulnerabilities? Is it possible to protect against them, and if so, how? All this we will discuss below.

    Quick reference

    Foreshadow, or L1TF is a whole group of vulnerabilities, which includes:

    • CVE-2018-3615 - for SGX bypass;
    • CVE-2018-3620 - to attack the kernel of the operating system, as well as the SMM mode (System Management Mode);
    • CVE-2018-3646 - to attack virtual machines.

    The authors of many publications express particular concern about the possibility of circumventing SGX protection: Specter and Metldown did not know how to do this, and this made any confidential data vulnerable. To understand how this alarm is justified, let us examine the principles of operation of the mechanism of the SGX.

    What is SGX and how to get around it

    The abbreviation SGX stands for Software Guard Extensions. This is the name of the set of Intel processor instructions used to allocate private areas of code and data. In 2015, one of the creators of SGX, Matthew Hoeskstra, published an article (see also Russian translation ), in which he highlighted the following goals for creating this technology:

    • enable application developers to protect critical data from unauthorized access or modification by malicious software running with higher privileges;
    • allow applications to ensure the integrity and confidentiality of sensitive data and code without interfering with the operation of the privilege system and without interfering with it to plan and control platform resources;
    • make the platform measure the trusted code and produce a signed certificate and other certificates using the application certifying that the code was correctly initialized in the trusted environment;
    • enable users to keep control over applications without at the same time limiting the freedom to install and remove applications and services;
    • allow developers to create trusted applications using tools and processes known to them;
    • provide increased performance of trusted applications;
    • Allow applications to determine trusted code and data areas even when an attacker physically controls the platform and can perform direct attacks on memory (see one example here ).

    The cited article marketing is much more than technical details. It describes in general terms what the SGX technology allows to do, but there is not a word about HOW this is done. We will tell about it in detail below. In our presentation, we will first rely on a detailed article published by the International Organization for Research in Cryptology (IACR, International Association for Cryptologic Research).

    SGX creates a protected region in memory - PRM (Processor Reserved Memory) , which is also called an enclave. The processor protects the enclave from any access attempts, including from the kernel, the hypervisor, and SMM (System Management Mode), as well as from access attempts from the peripheral devices.

    PRM has a special cache, the so-called EPC (Enclave Page Cache) , which consists of four kilobyte pages containing the enclave code and data. When you call a trusted function, the application "sees" only the enclave data; any external access, including from the OS, is prohibited.

    Any attempt to access the enclave is the procedure of so-called certification. The enclave requests a hardware-signed report, including information on its value. This report is sent to the certification server. The open part of the application key is sent to the enclave; then a private key is generated, depending on the enclave and platform. The key is encrypted with the signing key and saved for future use.

    As noted in the official publications of Intel, SGX can protect against all sorts of attacks on data and code: from the system and user software, as well as from the bootloader. But from the so-called side-channel-attacks SGX can not protect. SGX can not bypass the notorious Specter and Meltdown.

    Recently, however, attacks have appeared (actually, even before Foreshadow - see, for example, here ), which allow to bypass SGX protection. And Foreshadow is just the loudest and most sensational of them.

    The SGX documentation notes that "it is impossible to read from enclaves and it is impossible to write anything in them regardless of the presence of privileges of any level." However, in reality, this is not the case.

    This spring, information appeared about the attack called SGX Specter, which can be used to extract data from enclaves. As shown by researchers at Ohio State University (see, for example, here ), this is possible thanks to the “holes” in the SDK, through which developers can integrate SGX support into their applications. Among the affected SDK were Intel SGX SDK, Rust-SGX and Graphene-SGX. A detailed analysis of this attack can be found in this article ; A video demonstrating an example was also posted on Youtube.

    The video, of course, is not convincing: the mere fact of entering the enclave does not mean that important data can be stolen. Nevertheless, it must be stated: the integrity and confidentiality of the SGX mechanism is violated.

    Foreshadow gives isolation, using the so-called side-channel attack (side-channel attack).

    As in the notorious Specter and Meltdown, the vulnerability uses the mechanism of speculative execution of commands. It is based on the following point: when accessing memory via a virtual address resulting in an exception (terminal page fault) due to the lack of the Present flag in the PTE table (Page Table Entries), Intel processors speculatively calculate the physical address and load the data if they are available in L1 cache. Speculative calculations are carried out before checking the availability of data in physical memory and before checking the availability of this data for reading. If there is no Present flag in the PTE, then the operation is discarded; but the data at the same time "settle" in the cache and can be extracted from it. Data can be extracted absolutely at any physical address; this opens up extensive opportunities for intruders and allows, for example, to extract data on a host from a guest machine.

    However, the video looks, frankly, not very convincing and resembles numerous demonstrations of the work of Specter and Meltdown vulnerabilities, which were walked on the Internet at the beginning of this year: it seems that they managed to overcome the protection - but what next? Of course, SGX bypass is clearly not a good precedent.

    What to fear?

    Unlike the acclaimed Specter and Meltdown, Foreshadow threatens only Intel processors. The descriptions indicate that using this attack, you can extract not just confidential data from the enclave, but also a private certification key, which undermines the credibility of the entire SGX-ecosystem.

    Various variations of Foreshadow threaten the so-called System Management Mode (SMM), the core of the hypervisor operating system. Some experts point out that using Foreshadow you can steal data from virtual machines in a third-party cloud. There are publications where it is noted that the new attack even allows you to bypass the patches that were previously calculated to protect against Specter and Meltdown attacks.

    However - as in the case of Specter and Meltdown - all loud statements should be treated very carefully. Not a single case of theft of significant and confidential data using high-profile attacks has so far been recorded. The published exploit prototypes (as warned by the authors themselves) are nothing more than experimental samples, divorced from actual practice, and will not always work for everyone, especially when it comes to virtual machines. Therefore, it is too early to panic yet: in order not only to penetrate the confines of the enclave, but to extract really important information from it, you need to try very, very hard.

    At the moment, really serious attacks have been recorded.

    Patches and performance

    The topic of patches that protect against hardware vulnerabilities (and if not protecting, then leveling their consequences) is also very relevant. Recall the recent history of Specter and Meltdown: many measures were taken in a fire order, which led to not the best consequences: a sudden system reboot, a sharp drop in performance, etc. Microsoft even had to release updates that disable Intel patches. In the first three months of this year, 32 lawsuits were filed against Intel only .

    To publish information about the Foreshadow vulnerability, large companies reacted promptly: Intel , Red Hat , SUSE , VMware , Oracle made statements in this regard . Updates for Cisco products and for the Linux kernel were promptly released.

    Not without incidents: Intel quickly released microcode updates, but without strange incidents: the ban on publishing performance test results before and after the update was unexpectedly proclaimed (later, however, the ban was canceled ). What was it - hard to say. And the topic of the effect of patches on performance certainly deserves a separate study and a separate article. And it is possible that we will publish such an article in the near future.


    In this article, we have provided a brief overview of the Foreshadow class vulnerabilities. Naturally, it is impossible to tell about all aspects of vulnerabilities in the Foreshadow group within a single article. Therefore, we present a selection of useful links for those who want to learn more:

    If you have experience in analyzing hardware vulnerabilities and their consequences, welcome to comments.

    Also popular now: