ACM SIG Arch: Reflections on trusting SGX

Reflections on trusting SGX
by Mark Silberstein
Sep 25, 2018

The security community will remember the year of 2018 as the year of speculative execution attacks. Meltdown and Spectre, the recent Foreshadow (L1TF in Intel’s terminology), and their variants demonstrate how the immense processor design complexity, perpetual drive for higher performance, and subtle hardware-software interactions — all collude to create a major system security earthquake that is shaking the whole industry. Foreshadow stands out in that it wreaks havoc on Intel SGX, Intel’s recent instruction set extension for building trusted execution environments, which has been envisioned as a stronghold of security in future computing systems. In this blog I highlight the important differences between Foreshadow and other speculative execution attacks, and raise a few questions that require much more than just a technical solution.[…]

https://www.sigarch.org/reflections-on-trusting-sgx/

 

Intel-SA-00161: L1 Terminal Fault (L1TF) speculative execution side-channel attack (Foreshadow)

Security researchers have identified a speculative execution side-channel method called L1 Terminal Fault (L1TF). This method impacts select microprocessor products supporting Intel® Software Guard Extensions (Intel® SGX). Further investigation by Intel has identified two related applications of L1TF with the potential to impact additional microprocessors, operating systems, system management mode, and virtualization software. If used for malicious purposes, this class of vulnerability has the potential to improperly infer data values from multiple types of computing devices.[…]

https://foreshadowattack.eu/

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html

https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html

https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf.html

https://access.redhat.com/security/vulnerabilities/L1TF

https://www.redhat.com/en/blog/understanding-l1-terminal-fault-aka-foreshadow-what-you-need-know

https://blogs.technet.microsoft.com/virtualization/2018/08/14/hyper-v-hyperclear/

https://blogs.technet.microsoft.com/srd/2018/08/10/analysis-and-mitigation-of-l1-terminal-fault-l1tf/

https://www.us-cert.gov/ncas/current-activity/2018/08/14/Intel-Side-Channel-Vulnerability

 

Alexandre Adamski: Overview of Intel SGX – Part 1, SGX Internals

This blog-post provides the reader with an overview of the Intel SGX technology. In this first part, we explore the additions made to Intel platforms to support SGX, focusing on the processor and memory. We then explain the management and life cycle of an enclave. Finally, we detail two features of enclaves: secret sealing and attestation.[…]

https://blog.quarkslab.com/overview-of-intel-sgx-part-1-sgx-internals.html

 

Introducing graphene-ng: running arbitrary payloads in SGX enclaves

fig1

Jun 11, 2018 by Joanna Rutkowska

A few months ago, during my keynote at Black Hat Europe, I was discussing how we should be limiting the amount of trust when building computer systems. Recently, a new technology from Intel has been gaining popularity among both developers and researchers, a technology which promises a big step towards such trust-minimizing systems. I’m talking about Intel SGX, of course. Intel SGX caught my attention for the first time about 5 years ago, a little while before Intel has officially added information about it to the official Software Developer’s Manual. I’ve written two posts about my thoughts on this (then-upcoming) technology, which were a superposition of both positive and negative feelings. Over the last 2 years or so, together with my team at ITL, we’ve been investigating this fascinating technology a bit closer. Today I’d like to share some introductory information on this interesting project we’ve been working on together with our friends at Golem for several months now.[…]

https://blog.invisiblethings.org/2018/06/11/graphene-ng.html

 

 

CHIPSEC gets support for Nine more ACPI tables

Lots of news are filled with news about the latest  version of CHIPSEC released. I don’t see that, but there are some interesting new checkins w/r/t ACPI support:

ACPI_TABLE_SIG_BGRT = ‘BGRT’
ACPI_TABLE_SIG_LPIT = ‘LPIT’
ACPI_TABLE_SIG_ASPT = ‘ASPT’
+ACPI_TABLE_SIG_FIDT = ‘FIDT’
+ACPI_TABLE_SIG_HEST = ‘HEST’
+ACPI_TABLE_SIG_BERT = ‘BERT’
+ACPI_TABLE_SIG_ERST = ‘ERST’
+ACPI_TABLE_SIG_EINJ = ‘EINJ’
+ACPI_TABLE_SIG_TPM2 = ‘TPM2’
+ACPI_TABLE_SIG_WSMT = ‘WSMT’
+ACPI_TABLE_SIG_DBG2 = ‘DBG2’
+ACPI_TABLE_SIG_NHLT = ‘NHLT’
+ACPI_TABLE_SIG_MSCT = ‘MSCT’
+ACPI_TABLE_SIG_RASF = ‘RASF’
+ACPI_TABLE_SIG_SPMI = ‘SPMI’
+ACPI_TABLE_SIG_OEM1 = ‘OEM1’
+ACPI_TABLE_SIG_OEM2 = ‘OEM2’
+ACPI_TABLE_SIG_OEM3 = ‘OEM3’
+ACPI_TABLE_SIG_OEM4 = ‘OEM4’
+ACPI_TABLE_SIG_NFIT = ‘NFIT’

as well as some new SGX support… Fun!

https://github.com/chipsec/chipsec/commits/master

Google Asylo: SDK for apps that run in TEEs

[…]Today we’re excited to announce Asylo (Greek for “safe place”), a new open-source framework that makes it easier to protect the confidentiality and integrity of applications and data in a confidential computing environment. Asylo is an open-source framework and SDK for developing applications that run in trusted execution environments (TEEs). TEEs help defend against attacks targeting underlying layers of the stack, including the operating system, hypervisor, drivers, and firmware, by providing specialized execution environments known as “enclaves”. TEEs can also help mitigate the risk of being compromised by a malicious insider or an unauthorized third-party. Asylo includes features and services for encrypting sensitive communications and verifying the integrity of code running in enclaves, which help protect data and applications.[…]

https://cloudplatform.googleblog.com/2018/05/Introducing-Asylo-an-open-source-framework-for-confidential-computing.html

https://github.com/google/asylo

https://asylo.dev/

Intel SGX hardening patent, by Intel

PATENT ALERT. Engineers not wanting to be tainted by external patent info should not read this post. It is only the title/abstract of the patent, however.

.
.
.
.
.
.
.

Inventor: Volodymyr Pikhur, Atul A. Khare
Current Assignee: Intel Corp
Priority date: 2016-09-07

Non-enclave access prevention

A processing system includes an execution unit comprising a logic circuit to implement an architecturally-protected execution environment associated with a protected region in a memory, in which the execution unit is to execute application code stored in the protected region as a thread running in the architecturally-protected execution environment, determine that an access mode flag is set to a first value, detect an attempt by the thread to access data stored outside the protected region, and responsive to detecting the attempt and determining that the access mode flag is set to the first value, generate an exception.

https://patents.google.com/patent/US20180067873A1

INTEL-SA-00117: Intel SGX Elevation of Privilege

Intel® SGX SDK Edger8r and Intel® Software Guard Extensions Platform Software Component
Intel ID: INTEL-SA-00117
Product family: Intel® SGX
Impact of vulnerability: Elevation of Privilege
Severity rating: Important
Original release: Mar 19, 2018

[…]CVE-2018-3626: The Edger8r tool in the Intel® Software Guard Extensions (SGX) Software Development Kit (SDK) before version 2.1.2 (Linux) and 1.9.6 (Windows) may generate code that is susceptible to a side channel attack, potentially allowing a local user to access unauthorized information. CVE-2018-5736: An elevation of privilege in Intel® Software Guard Extensions Platform Software Component before 1.9.105.42329 allows a local attacker to execute arbitrary code as administrator. CVE-2018-3626: Recently it was reported that the Edger8r Tool, a software component of the Intel® Software Guard Extensions (SGX) Software Development Kit (SDK), may generate C source code potentially leading to a software based side-channel vulnerability. […]Intel would like to thank Jo Van Bulck, Frank Piessens, and Raoul Strackx of Ku Leuven University for reporting CVE-2018-3626 and working with us on coordinated disclosure.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00117&languageid=en-fr

SgxPectre Attacks: Leaking Enclave Secrets via Speculative Execution

SgxPectre Attacks: Leaking Enclave Secrets via Speculative Execution
Guoxing Chen, Sanchuan Chen, Yuan Xiao, Yinqian Zhang, Zhiqiang Lin, Ten H. Lai
(Submitted on 25 Feb 2018)

This paper presents SgxPectre Attacks that exploit the recently disclosed CPU bugs to subvert the confidentiality of SGX enclaves. Particularly, we show that when branch prediction of the enclave code can be influenced by programs outside the enclave, the control flow of the enclave program can be temporarily altered to execute instructions that lead to observable cache-state changes. An adversary observing such changes can learn secrets inside the enclave memory or its internal registers, thus completely defeating the confidentiality guarantee offered by SGX. To demonstrate the practicality of our SgxPectre Attacks, we have systematically explored the possible attack vectors of branch target injection, approaches to win the race condition during enclave’s speculative execution, and techniques to automatically search for code patterns required for launching the attacks. Our study suggests that any enclave program could be vulnerable to SgxPectre Attacks since the desired code patterns are available in most SGX runtimes (e.g., Intel SGX SDK, Rust-SGX, and Graphene-SGX).

https://arxiv.org/abs/1802.09085

 

SGX After Spectre and Meltdown: Status, Analysis and Remediations

SGX After Spectre and Meltdown: Status, Analysis and Remediations
Posted on January 25, 2018 by idfusionllc

Much has been written about the recently disclosed micro-architectural cache probing attacks named in the title of this document. These attacks, while known as a possibility for some time, have created significant concerns and remediation activity in the industry, secondary to the significant confidentiality threats they pose. These attacks are particularly problematic since they evade long standing protections that the industry has used as foundational constructs in the security design of modern operating systems.

While the threats to operating system protections have undergone significant discussion, there has been little official information surrounding the impact of this new threat class to Intel’s Software Guard eXtension (SGX) technology. This document is intended to provide support for system security architects and software engineers with respect to the impact of this new class of attack on SGX security guarantees. The development of this document was inspired by dialogue on the Intel SGX developer’s forum surrounding whether or not enclaves provide credible security guarantees in the face of these new threats.

Hardware and microcode enhancements introduced in the Intel Skylake micro-architecture provide the framework for the SGX Trusted Execution Environment (TEE). The SGX security architecture uses the notion of an enclave, which is an area of memory which contains data and code which can only be referenced by the enclave itself. Unauthorized access to these protected memory regions are blocked regardless of the privilege level of the context of execution attempting the access. As a result the premise is that enclaves will provide confidentiality and integrity guarantees even if the hardware, BIOS, hypervisor or operating system are compromised.[…]

https://software.intel.com/en-us/forums/intel-software-guard-extensions-intel-sgx/topic/754168

SGX After Spectre and Meltdown: Status, Analysis and Remediations

Aurora: Providing Trusted System Services for Enclaves On an Untrusted System

Aurora: Providing Trusted System Services for Enclaves On an Untrusted System
Hongliang Liang, Mingyu Li, Qiong Zhang, Yue Yu, Lin Jiang, Yixiu Chen
(Submitted on 10 Feb 2018)

Intel SGX provisions shielded executions for security-sensitive computation, but lacks support for trusted system services (TSS), such as clock, network and filesystem. This makes \textit{enclaves} vulnerable to Iago attacks~\cite{DBLP:conf/asplos/CheckowayS13} in the face of a powerful malicious system. To mitigate this problem, we present Aurora, a novel architecture that provides TSSes via a secure channel between enclaves and devices on top of an untrusted system, and implement two types of TSSes, i.e. clock and end-to-end network. We evaluate our solution by porting SQLite and OpenSSL into Aurora, experimental results show that SQLite benefits from a \textit{microsecond} accuracy trusted clock and OpenSSL gains end-to-end secure network with about 1ms overhead.

https://arxiv.org/abs/1802.03530

Upcoming Intel SGX Features Explained: Improved Virtualization, Configuration Management, and Key Sharing

Upcoming Intel® SGX Features Explained: Improved Virtualization, Configuration Management, and Key Sharing
Jethro Beekman
February 22nd, 2018
In an update to the Intel Software Developer’s Manual (SDM), Intel detailed upcoming changes to the Intel® SGX instruction set. The new features improve Enclave Page Cache management in virtualized environments and allow the addition of additional information to sealing key derivation and attestation reports. The improvements allow for better multi-tenancy with EPC oversubscription and easier configuration and software update management. I will go into detail on each of these in this post.[…]

https://www.fortanix.com/blog/2018/02/upcoming-intel-sgx-features-explained/

EnclaveDB: A Secure Database using SGX

https://www.computer.org/csdl/proceedings/sp/2018/4353/00/index.html

EnclaveDB: A Secure Database using SGX
Christian Priebe , Imperial College London
Kapil Vaswani , Microsoft Research
Manuel Costa , Microsoft Research
We propose EnclaveDB, a database engine that guarantees confidentiality, integrity, and freshness for data and queries. EnclaveDB guarantees these properties even when the database administrator is malicious, when an attacker has compromised the operating system or the hypervisor, and when the database runs in an untrusted host in the cloud. EnclaveDB achieves this by placing sensitive data (tables, indexes and other metadata) in enclaves protected by trusted hardware (such as Intel SGX). EnclaveDB has a small trusted computing base, which includes an in-memory storage and query engine, a transaction manager and pre-compiled stored procedures. A key component of EnclaveDB is an efficient protocol for checking integrity and freshness of the database log. The protocol supports concurrent, asynchronous appends and truncation, and requires minimal synchronization between threads. Our experiments using standard database benchmarks and a performance model that simulates large enclaves show that EnclaveDB achieves strong security with low overhead (up to 40% for TPC-C) compared to an industry strength in-memory database engine.

https://www.computer.org/csdl/proceedings/sp/2018/4353/00/435301a405-abs.html

https://www.microsoft.com/en-us/research/publication/enclavedb-a-secure-database-using-sgx/

https://www.microsoft.com/en-us/research/uploads/prod/2018/02/enclavedb.pdf

DelegaTEE: Brokered Delegation Using Trusted Execution Environments

DelegaTEE: Brokered Delegation Using Trusted Execution Environments

Sinisa Matetic and Moritz Schneider and Andrew Miller and Ari Juels and Srdjan Capkun

We introduce a new concept called brokered delegation. Brokered delegation allows users to flexibly delegate credentials and rights for a range of service providers to other users and third parties. We explore how brokered delegation can be implemented using novel trusted execution environments (TEEs). We introduce a system called DelegaTEE that enables users (Delegatees) to log into different online services using the credentials of other users (Owners). Credentials in DelegaTEE are never revealed to Delegatees and Owners can restrict access to their accounts using a range of rich, contextually dependent delegation policies. DelegaTEE fundamentally shifts existing access control models for centralized online services. It does so by using TEEs to permit access delegation at the user’s discretion. DelegaTEE thus effectively reduces mandatory access control (MAC) in this context to discretionary access control (DAC). The system demonstrates the significant potential for TEEs to create new forms of resource sharing around online services without the direct support from those services. We present a full implementation of DelegaTEE using Intel SGX and demonstrate its use in four real-world applications: email access (SMTP/IMAP), restricted website access using a HTTPS proxy, e-banking/credit card, and a third-party payment system (PayPal).

https://eprint.iacr.org/2018/160

https://eprint.iacr.org/2018/160.pdf

Monotonic Counter in Intel SGX and ME

Some notes on the Monotonic Counter in Intel SGX and ME
Posted on November 10, 2017 by daveti

SGX sealing is vulnerable to rollback attacks as the enclave is not able to tell if the sealed data is the latest or a old copy. To mitigate this attack, monotonic counter (MC) has been introduced in Intel SGX SDK 1.8. This post looks into some implementation details inside Intel SGX SDK.[…]

Some notes on the Monotonic Counter in Intel SGX and ME

Scotch: Combining SGX and SMM to Monitor Cloud Resource Usage

First Online: 12 October 2017
Part of the Lecture Notes in Computer Science book series (LNCS, volume 10453)

The growing reliance on cloud-based services has led to increased focus on cloud security. Cloud providers must deal with concerns from customers about the overall security of their cloud infrastructures. In particular, an increasing number of cloud attacks target resource allocation in cloud environments. For example, vulnerabilities in a hypervisor scheduler can be exploited by attackers to effectively steal CPU time from other benign guests on the same hypervisor. In this paper, we present Scotch, a system for transparent and accurate resource consumption accounting in a hypervisor. By combining x86-based System Management Mode with Intel Software Guard Extensions, we can ensure the integrity of our accounting information, even when the hypervisor has been compromised by an escaped malicious guest. We show that we can account for resources at every task switch and I/O interrupt, giving us richly detailed resource consumption information for each guest running on the hypervisor. We show that using our system incurs small but manageable overhead—roughly 1 μ
s every task switch or I/O interrupt. We further discuss performance improvements that can be made for our proposed system by performing accounting at random intervals. Finally, we discuss the viability of this approach against multiple types of cloud-based resource attacks.

https://link.springer.com/chapter/10.1007/978-3-319-66332-6_18