PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey of Published Attacks on Intel SGX

Alexander Nilsson, Pegah Nikbakht Bideh, Joakim Brorsson

arXiv:2006.13598v1cs.CR

TL;DR

SGX protects code and data from untrusted system software, but published attacks challenge those guarantees. This paper comprehensively surveys SGX-specific attacks, groups them into seven categories, and reviews their mitigations, finding that mitigation exists for all surveyed attacks although practical implementation can be difficult.

  • Problem

    Many flaws and attacks target SGX despite its protection of enclave code and data, motivating a comprehensive account of the attack landscape and available defenses.

  • Method

    The paper surveys known SGX-specific attacks, categorizes them into seven groups by implementation details, and classifies relevant mitigation techniques.

  • Results

    The survey identifies more than 20 attacks and reports mitigation strategies for all of them, using microcode, system-design, compiler/SDK, or application-design techniques.

  • Takeaways & Limitations

    Mitigations exist across the surveyed attacks, but those requiring correct application design may be difficult to implement completely in practice.

  • Takeaways & Limitations

    Cache attacks are outside Intel’s threat model and often require enclave-specific mitigations; for one attestation attack, the survey found no indication that Intel had updated the affected enclaves.

Abstract

from arXiv · show

Intel Software Guard Extensions (SGX) provides a trusted execution environment (TEE) to run code and operate sensitive data. SGX provides runtime hardware protection where both code and data are protected even if other code components are malicious. However, recently many attacks targeting SGX have been identified and introduced that can thwart the hardware defence provided by SGX. In this paper we present a survey of all attacks specifically targeting Intel SGX that are known to the authors, to date. We categorized the attacks based on their implementation details into 7 different categories. We also look into the available defence mechanisms against identified attacks and categorize the available types of mitigations for each presented attack.

I. INTRODUCTION

SGX is a TEE that isolates sensitive code and data from untrusted system software, reducing reliance on the OS kernel and hypervisor. This survey reviews the many attacks that target SGX and the mitigations available for them.

  • Motivation: SGX enclaves isolate code and data from applications, the OS kernel, and the hypervisor while supporting arbitrary code on general hardware.This makes SGX suitable for cloud environments with untrusted surrounding software.
  • Motivation: Without TEEs, virtualization requires applications to trust the OS kernel, hypervisor, and cloud provider.
  • Motivation: SGX reduces the trusted computing base by rooting trust in the application code and CPU hardware rather than a larger software chain.The comparison is made with TPM-based trusted computing, which depends on more extensive code and firmware.
  • Problem: Researchers have published a relatively large number of flaws and attacks against SGX in recent years.
  • Contribution: The paper presents a comprehensive review of SGX-specific attacks and the known countermeasures or mitigations for them.The review covers controlled-channel, cache, speculative-execution, branch-prediction, rogue-data-cache, MDS, and software fault-injection attacks.

A. SGX Overview

SGX enclaves run as user-space software but protect their memory from privileged and untrusted software through hardware-supported isolation. They remain integrated with ordinary applications and virtualization environments while relying on the OS for services.

  • Privilege model: Intel’s x86-64 ISA places user applications in ring 3 and the OS kernel in the more privileged ring 0.Ring 0 handles resource allocation, device management, context switching, and page swapping.
  • Privilege model: An SGX enclave runs as a ring-3 application in either VMX root or non-root mode, despite treating system software as untrusted.The enclave relies on the OS kernel for scheduling, page swapping, and interrupt handling.
  • Memory protection: Enclave code and data reside in the EPC within processor-reserved memory, whose contents are protected against DMA and external memory snooping.The reserved memory is transparently encrypted and integrity protected before crossing the memory bus.
  • Integration: Enclaves operate like dynamically loadable modules in application address spaces, making them comparatively easy to integrate into existing programs.
  • Integration: Enclaves can be entered only through well-defined entry points specified by the enclave author.

B. The SGX Lifetime

The untrusted OS manages enclave creation, initialization, scheduling, and destruction through SGX instructions. Enclave entry requires controlled structures and predefined entry points, while initialization measures code and data for attestation.

  • Lifecycle management: The untrusted OS kernel manages enclave lifetime, including page swapping, interrupts, and CPU-core scheduling.SGX introduces instructions that facilitate these services.
  • Creation: ECREATE allocates the enclave’s protected SECS page, which stores security-critical metadata.
  • Initialization: EADD adds pages to the enclave’s protected virtual address space, while EEXTEND measures code and data for software attestation.Both instructions are available only while the SECS remains uninitialized.
  • Initialization: The OS issues EINIT only after obtaining an EINIT Token Structure through Intel’s signed Launch Enclave.The Launch Enclave is identified by a key whose public part is hardcoded into the SGX implementation.
  • Destruction: EREMOVE deallocates enclave pages only when no logical processor owns them and destroys the enclave after its other pages are removed.
  • Execution control: Each logical processor uses a Thread Control Structure, and enclave entry uses EENTER to jump only to predefined addresses.EENTER saves registers for later restoration when entering enclave mode.

6) Synchronous Exit:

SGX exits enclave mode either explicitly or in response to hardware events, saving and restoring execution state as needed. Eviction protects pages with encryption, integrity checks, and freshness mechanisms, while attestation provides signed evidence about enclave software.

  • Exit handling: EEXIT explicitly leaves enclave mode and restores the registers saved by EENTER.
  • Exit handling: A hardware exception triggers AEX, which saves the current enclave context and restores the state saved by EENTER before invoking the default handler.
  • Resumption: After interrupt handling, ERESUME returns the processor to enclave mode and continues the interrupted execution.
  • Eviction: EWB encrypts and integrity-protects an evicted page with an enclave-specific symmetric key and uses nonces to ensure freshness.The normal page-swapping mechanism can then flush the page to disk.
  • Attestation: Remote attestation uses an SGX-generated signature to identify enclave software and optional enclave data for verification by a remote party.

III. ATTACKS ON SGX

The survey organizes published SGX attacks by implementation details, while emphasizing that enclave security also depends on secure interfaces and trusted software components. Controlled-channel attacks exploit the untrusted kernel’s control over enclave services, with techniques ranging from page-fault monitoring to instruction-level tracing.

  • Attack taxonomy: The survey groups SGX attacks into 7 categories based on implementation details and unifies terminology across surveyed papers.Most surveyed papers are self-categorized; the authors consolidate common terminology using technical details.
  • Software and interface risks: SDKs help enforce secure interfaces through flag sanitation, stack restoration, pointer checks, and register-leakage prevention, but SDK vulnerabilities affect dependent enclaves.The cited SDK study found multiple vulnerabilities in all tested open-source enclave-development SDKs.
  • Implementation-specific attacks: Iago attacks exploit applications’ implicit trust in the kernel by returning false system-call responses that induce self-damaging operations.The malicious kernel remains outside the TCB but influences enclave behavior through system-call results.
  • Implementation-specific attacks: ROP can circumvent SGX hardware protections and achieve a total security break, while AsyncShock targets synchronization bugs in multithreaded enclaves.AsyncShock is an attack tool designed to simplify reliable exploitation of synchronization bugs.
  • Controlled-channel attacks: Controlled-channel attacks use the untrusted kernel’s near-total platform control to construct side channels against enclaves relying on kernel services.The term was coined by Xu et al. in 2015.
  • Controlled-channel attacks: Attackers monitor memory at page-level granularity through page faults, while SGX-Step uses APIC timers, interrupts, and page-table tracking to single-step enclave instructions.SGX-Step has also served as a framework for multiple other SGX attacks.
  • Controlled-channel attacks: Other controlled-channel variants obtain instruction-level timing leakage, exploit 32-bit memory segmentation, or monitor TLB accessed flags without interrupting the enclave.Sneaky page monitoring periodically accesses and resets the TLB accessed flag.

B. Cache-attacks [20]–[25]

Cache attacks exploit measurable cache-hierarchy effects from enclave memory activity, while branch-prediction and speculative-execution attacks reveal control flow or infer data through transient CPU-state changes. The surveyed attacks apply techniques including Prime+Probe and target multiple microarchitectural structures.

  • Cache attacks: Cache-based timing attacks exploit cache-hierarchy effects from DRAM loads that remain measurable outside the enclave.The survey states that SGX enclaves are vulnerable to cache attacks against secret-dependent processing, potentially with greater attacker capability.
  • Cache attacks: Common cache-extraction techniques include Flush+Reload, Prime+Probe, Evict+Time, Evict+Reload, and Flush+Flush.
  • Cache attacks: Sneaky page monitoring uses Prime+Probe to increase attack granularity, while CacheZoom and other attacks also apply Prime+Probe to SGX caches.Prime+Probe is used across attacks involving cache timing, malicious enclaves, same-core hyperthreading, and Intel’s provisioning enclave.
  • Cache attacks: MemJam exploits read-after-write false dependencies caused by 4K aliasing in the L1 cache, using a methodology resembling Evict+Time.
  • Branch prediction attacks: Branch Shadowing reveals fine-grained enclave control flow and can break the security of several enclave-based constructs.
  • Speculative execution attacks: Spectre variants induce mispredicted speculative execution whose discarded results nevertheless alter CPU caches, enabling attackers to infer data from vulnerable co-hosted processes.The original variants were bounds check bypass and branch target injection.
  • Speculative execution attacks: SgxPectre extracted secret sealing and attestation keys from Intel-signed quoting enclaves, while SpectreRSB uses the return stack buffer for speculative prediction.

E. Rogue Data Cache Loads [34]

Rogue data cache load attacks exploit transient or stale data in CPU buffering structures to bypass protections affecting SGX and other security boundaries. The surveyed work includes Foreshadow, MDS attacks, CacheOut, SGAxe, and CrossTalk, with differing targeting precision and scope.

  • Rogue data cache loads: Meltdown infers unauthorized memory through transient out-of-order results, whereas SGX’s abort-page semantics require Foreshadow to revoke enclave-page permissions first.Foreshadow uses mprotect so page-table permission checks fail before SGX returns its dummy result.
  • Rogue data cache loads: Foreshadow-NG generalized L1TF into Foreshadow-SGX, Foreshadow-OS, and Foreshadow-VMM, although only Foreshadow-SGX applies to SGX.
  • Microarchitectural data sampling: MDS attacks bypass common security boundaries, including SGX enclaves, by leaking information from implementation-specific and undocumented microarchitectural structures.The surveyed class includes Fallout, RIDL, and ZombieLoad.
  • Microarchitectural data sampling: SGX is safe from Fallout because flushing the store buffer prevents that attack, but it remains vulnerable to the other cited MDS attacks.Fallout targets kernel writes leaked from the store buffer into user space.
  • Microarchitectural data sampling: RIDL and CacheOut exploit line fill buffers, with CacheOut forcing L1D contention to target and evict data more precisely than uncontrolled leakage.RIDL bypassed mitigations deployed for Spectre, Meltdown, and Foreshadow at its publication.
  • Microarchitectural data sampling: ZombieLoad leaks stale line-fill-buffer data and can leak memory-load results regardless of whether the requested data is present in L1D.
  • Microarchitectural data sampling: SGAxe uses CacheOut to extract sealing and attestation keys from Intel’s Quoting Enclave, enabling forged attestation quotes.
  • Microarchitectural data sampling: CrossTalk samples a staging buffer shared across cores, defeating core isolation as a mitigation and demonstrating cross-core enclave attacks.The staging buffer is described as an undocumented component shared between all cores.

G. Software-based Fault Injection Attacks [44]

The survey places software-based fault injection among its attack categories and distinguishes applicable Intel SGX attacks from out-of-scope ARM-specific and denial-of-service attacks. Plundervolt abuses privileged voltage controls to corrupt enclave computations and recover cryptographic keys.

  • Software-based fault injection attacks: CLKscrew targets ARM TrustZone through dynamic frequency scaling, so it does not affect Intel SGX.
  • Software-based fault injection attacks: Plundervolt abuses privileged x86 voltage-scaling interfaces to reliably corrupt computations inside victim SGX enclaves.The attack briefly decreases CPU voltage during enclave computation.
  • Software-based fault injection attacks: Plundervolt can reconstruct full cryptographic keys with negligible computational effort after injecting faults into protected enclave computations.
  • Scope boundary: SGX-Bomb and RowHammer would fit this attack category, but denial-of-service attacks are excluded from the survey’s scope.
  • Mitigation scope: The mitigation survey categorizes defenses as microcode patches, system design, compiler/SDK techniques, and application design.
  • Mitigation scope: Purely theoretical defenses requiring hardware or ISA changes, such as Sanctum and Autarky, are excluded from the mitigation survey.

A. Microcode patch

The survey groups SGX mitigations into microcode patches, system design, compiler/SDK changes, and application design. This section emphasizes defenses implemented through compilers, SDKs, runtime monitoring, and supporting-system changes.

  • A. Microcode patch: Microcode patches are usually the most effective mitigation because they directly change CPU behavior, although some attacks require redesigning supporting systems.The survey notes that microcode is manufacturer-controlled low-level software, while supporting-system redesign may be needed when patches are insufficient.
  • A. Microcode patch: Some mitigations require attestation services and supporting enclaves to process new system-state information introduced by microcode patches.The survey identifies Launcher, Provisioning, and Quoting Enclaves as examples of supporting services affected by system-design changes.
  • A. Microcode patch: Application-independent defenses can be implemented in compilers or enclave SDKs, allowing developers to opt in while accepting performance impacts and drawbacks.The survey presents compiler- and SDK-level approaches as transparent to enclave developers when adopted.
  • A. Microcode patch: Compiler extensions can transform control flow, block Hyper-Threading side channels, or terminate sensitive operations after suspicious interrupts.Examples include ZigZagger, runtime control-flow randomization, shadow threads, and T-SGX.
  • A. Microcode patch: TSX-based defenses detect or prevent controlled-channel attacks by monitoring interrupts, execution timing, or page-table activity.T-SGX aborts after repeated interrupts, Déjà Vu detects timing deviations, and Heisenberg Defence proactively protects against page-table monitoring.

D. Application design

Application design remains a major mitigation layer because some attacks are enclave-specific or outside Intel’s threat model. The survey finds that mitigation coverage is broad, but feasibility and residual requirements vary across attacks.

  • D. Application design: Application design is the fallback when other defenses fail, requiring enclave authors to build code that avoids exploitable side channels.The survey frames secure and side-channel-protected enclave construction as the author’s responsibility when other measures are unavailable.
  • D. Application design: Compiler-assisted removal of data-dependent memory accesses, TSX-wrapped secret operations, dummy accesses, and ORAM can reduce leakage from memory behavior.These techniques target page-fault and cache side channels by hiding or regularizing secret-dependent accesses.
  • D. Application design: Table I summarizes attack properties and mitigation status, with categorized attacks generally mitigated or partially mitigated by four mitigation types.The four types are microcode patch, system design, compiler/SDK, and application design.
  • D. Application design: Controlled-channel and branch-prediction attacks usually share compiler/SDK or application-design mitigations because attacks within a category have similar requirements.The survey identifies this similarity as a general pattern across attack categories.
  • D. Application design: Cache attacks require enclave-specific application changes because they are outside Intel’s threat model and depend strongly on the targeted enclave implementation.For an attack against the attestation service, the survey states that updating Intel-provided enclaves may be the only viable option.
  • D. Application design: Most speculative-execution, rogue-data-cache-load, MDS, and software fault-injection attacks are mitigated with microcode patches, sometimes combined with attestation updates.The survey lists Off-Limits, SgxPectre, Foreshadow, Foreshadow-NG, and PlunderVolt among examples.
  • D. Application design: Some effective mitigations impose additional system requirements, such as disabling Hyper-Threading and recording its status during attestation and sealing.These requirements arise in the mitigation strategy against Foreshadow.
  • D. Application design: CacheOut remained only partially mitigated because Intel had released patches for most MDS attacks but not for CacheOut at the time of writing.The survey reports that Intel had promised a future patch for CacheOut.

VI. CONCLUSIONS

The survey identifies more than 20 SGX attacks using side channels and active attackers and finds mitigation strategies for all of them. However, practical feasibility varies, especially for defenses dependent on completely correct application design.

  • VI. CONCLUSIONS: More than 20 SGX attacks using side channels and active attackers were identified in the literature.The attacks are compiled in Table I.
  • VI. CONCLUSIONS: Mitigation strategies exist for all surveyed attacks, but some are more feasible in practice than others.The conclusion distinguishes mitigation availability from practical deployability.
  • VI. CONCLUSIONS: The recent number of SGX side-channel attacks suggests that additional attacks may remain undiscovered.The survey says this possibility should be considered when evaluating whether and how to employ SGX.
Loading 2006.13598v1…