PaperlayerView exact revision on arXiv

Source-linked AI summary

Spectre Returns! Speculation Attacks using the Return Stack Buffer

Esmaeil Mohammadian Koruyeh, Khaled Khasawneh, Chengyu Song, Nael Abu-Ghazaleh

arXiv:1807.07940v1cs.CR

TL;DR

Spectre attacks exploit speculative execution to expose data across protection boundaries, motivating the paper’s study of attack triggers beyond the branch predictor. The paper introduces SpectreRSB, which manipulates the return stack buffer, demonstrates local and SGX attacks, and analyzes cross-boundary variants. The results show that existing defenses do not stop all attacks, while RSB refilling interferes with some kernel-switch attacks but does not protect every setting.

  • Problem

    Existing Spectre attacks exploit speculative execution to exfiltrate sensitive data across protection boundaries, but the security implications of other speculation predictors require investigation.

  • Method

    The paper constructs SpectreRSB attacks that manipulate the return stack buffer to trigger speculative execution of payload gadgets, including local, cross-thread, kernel, cross-process, and SGX scenarios.

  • Results

    The authors demonstrate practical same-process and SGX attacks, report that the SGX attack bypasses known defenses, and find that several practical deployments remain vulnerable.

  • Takeaways & Limitations

    Defenses should address speculation through the RSB, including broader RSB refilling and protection when entering SGX enclaves.

  • Takeaways & Limitations

    The analyzed attacks assume colluding threads, and the cross-process attack was not completely demonstrated because identifying victim gadgets and synchronizing execution pose challenges.

Abstract

from arXiv · show

The recent Spectre attacks exploit speculative execution, a pervasively used feature of modern microprocessors, to allow the exfiltration of sensitive data across protection boundaries. In this paper, we introduce a new Spectre-class attack that we call SpectreRSB. In particular, rather than exploiting the branch predictor unit, SpectreRSB exploits the return stack buffer (RSB), a common predictor structure in modern CPUs used to predict return addresses. We show that both local attacks (within the same process such as Spectre 1) and attacks on SGX are possible by constructing proof of concept attacks. We also analyze additional types of the attack on the kernel or across address spaces and show that under some practical and widely used conditions they are possible. Importantly, none of the known defenses including Retpoline and Intel's microcode patches stop all SpectreRSB attacks. We believe that future system developers should be aware of this vulnerability and consider it in developing defenses against speculation attacks. In particular, on Core-i7 Skylake and newer processors (but not on Intel's Xeon processor line), a patch called RSB refilling is used to address a vulnerability when the RSB underfills; this defense interferes with SpectreRSB's ability to launch attacks that switch into the kernel. We recommend that this patch should be used on all machines to protect against SpectreRSB.

1 Introduction

SpectreRSB introduces a Spectre-class attack that manipulates the return stack buffer rather than the branch predictor to trigger speculative disclosure across protection boundaries. The paper demonstrates local and SGX attacks, analyzes broader attack settings, and finds that several practical deployments remain vulnerable despite deployed defenses.

  • Novel attack vector: SpectreRSB exploits the return stack buffer (RSB) to speculatively execute a payload gadget that reads and exposes sensitive information.The RSB predicts return addresses using an internal hardware stack, typically with 16 entries.
  • Novel attack vector: User code can manipulate the RSB by changing or removing the software-stack return address after a call pushes a value to the RSB.The stale RSB value then no longer matches the software stack.
  • Attack scope: The paper develops an RSB-based analogue of Spectre variant 1 and analyzes pollution across hardware threads, processes, virtual machines, and SGX compartments.The basic same-address-space attack illustrates the principles, while the cross-boundary cases extend the attack surface.
  • Attack scope: The SGX attack uses a malicious operating system to pollute the RSB and exposes data outside an SGX compartment while bypassing software and microcode patches on the tested machine.The paper also discusses kernel and cross-process attacks, though some require difficult-to-find ingredients or remain incomplete.
  • Defenses and implications: Several practical deployments are vulnerable because existing defenses do not mitigate all SpectreRSB attacks.The paper presents SpectreRSB as a dangerous speculation attack that extends the known speculation threat surface.
  • Scope boundary: The authors did not demonstrate attacks on AMD or ARM processors, although those processors also use RSBs to predict return addresses.The attacks were reported to Intel, AMD, and ARM security teams.

2 Speculation Attacks and Defenses

Speculation attacks exploit delayed validation, microarchitectural side effects, and predictor manipulation to disclose data, while defenses target page mappings, speculative barriers, indirect branches, and predictor state. Spectre variant 1 demonstrates the attack pattern, whereas RSB refilling addresses a specific underfill condition on some Intel processors but leaves other lines unpatched.

  • Speculation attacks: Speculative execution improves modern CPU performance, but squashed instructions can leave cache and other microarchitectural side effects that reveal otherwise inaccessible information.These effects occur even when speculative instructions do not commit and their direct effects are invisible.
  • Speculation attacks: Spectre attacks rely on deep pipeline validation, inferable speculative side effects, predictor manipulation, and delayed permission checks.The attack model combines these properties to access data outside the attacker’s privilege domain.
  • Spectre variant 1: In Spectre variant 1, an attacker trains the branch predictor, enlarges the speculation window by evicting array1_size, and uses an out-of-bounds offset to encode secret data through array2’s cache state.The victim’s array1 value determines an array2 access that the attacker can infer through a cache side channel.
  • Spectre variant 1: The resulting cache access can disclose the secret value because the trained predictor speculatively executes the memory accesses before the branch resolves.This mechanism allows the attacker to infer the selected index from cache behavior.
  • Defenses: KPTI unmaps kernel pages in user mode to prevent speculative user-to-kernel access, but it cannot prevent attacks within the same privilege mode and may impose substantial overhead.KPTI remaps kernel pages during a switch into the kernel.
  • Defenses: Retpoline replaces indirect branches with returns and relies on RSB behavior to prevent indirect branch target injection, requiring source access and recompilation.It deliberately pollutes the RSB with a benign gadget and assumes attackers cannot pollute that structure.
  • Defenses: RSB refilling fills the RSB with benign delay-gadget addresses on kernel entry to address underfill, but unpatched pre-Skylake Core i7 and Intel Xeon processors remain vulnerable to SpectreRSB.On Intel CPUs checked, an empty RSB causes speculation to switch to the branch predictor.

3 Attack Principles: Reverse Engineering the Return Stack Buffer

The Return Stack Buffer predicts return targets by tracking call return addresses, but mismatches between the RSB and software stack can induce attacker-controlled speculative execution. The paper identifies four sources of RSB misspeculation, including direct pollution and reuse across execution contexts.

  • RSB operation: The RSB is a hardware stack that pushes call return addresses and predicts the target when the matching return executes.This structure is typically 16 entries deep and supports speculation about return instructions.
  • RSB operation: An RSB mismatch occurs when its predicted return address differs from the software stack, causing speculation to the address stored in the RSB.Intentional triggering of this mismatch creates a Spectre-like attack vector.
  • Sources of misspeculation: RSB overfill or underfill can overwrite older entries, eventually leaving no valid RSB value when nested calls return.On checked Intel CPUs, an empty RSB switches prediction to the branch predictor, while AMD appears not to follow this strategy.
  • Sources of misspeculation: Direct pollution lets an attacker alter or remove the software-stack return address while the original RSB value remains, producing a controllable mismatch.The attacker can control the misspeculation address through the call address.
  • Sources of misspeculation: Speculative calls can pollute the RSB, while call/return transformations such as push-and-jump or pop-and-jump can desynchronize it from the software stack.The paper notes a possible but unused connection to bypassing SMEP through a kernel gadget.
  • Sources of misspeculation: Across execution contexts, a subsequent thread, operating-system transition, or SGX context may reuse RSB values left by a prior thread.The operating-system case depends on RSB refilling not being implemented.

4 SpectreRSB: Basic attack example

The basic SpectreRSB attack uses a manipulated software stack to make a return speculatively execute a payload that reads sensitive data. It avoids branch-predictor speculation, but the demonstrated kernel-memory variant requires an unpatched setting and disabled SMEP.

  • Attack setup: The basic attack launches from a process toward inaccessible data by manipulating the RSB rather than mistraining a branch predictor.The paper presents it as a simple illustration of SpectreRSB principles, while noting that it is unlikely to be practical with high-level sandboxing primitives.
  • Attack limitations: Kernel-memory access through this basic attack is blocked by KPTI for user code, while the demonstrated kernel attack requires a machine without SMEP enabled.The paper reports demonstrating that attack with SMEP disabled.
  • Attack setup: The gadget pushes a return address into the RSB, modifies the software stack, and creates a mismatch that redirects the return speculatively to the payload gadget.The payload reads the secret and uses a cache-access pattern to expose its value.
  • Attack setup: Flushing the true return address from the cache enlarges the speculation window before the architectural return commits to its actual destination.The true return goes back to main while the speculative path executes the secret-dependent payload.

5 Attacks across different threads/processes

SpectreRSB can cross thread or process contexts by polluting the shared RSB before a victim returns, although these attacks depend on hardware conditions and synchronization. The paper demonstrates a colluding-thread attack and reports a kernel-return variant with SMEP disabled, but no process-boundary proof of concept.

  • Cross-context attack model: Cross-context attacks exploit RSB reuse after a context switch, potentially targeting another process or virtual machine when RSB refilling is absent.The relevant machines include pre-Skylake systems and Intel Xeon processors.
  • Cross-context attack model: The basic flow pollutes the RSB with a victim-space payload address, yields to the victim, and relies on the victim’s return to begin speculative execution there.The attacker then resumes to measure the resulting leakage.
  • Attack 2a: The colluding-thread attack succeeded, proving that SpectreRSB can operate from one thread to another, but its user-mode return cannot read kernel data.Useful extensions would require a kernel-mode return or a different-process victim.
  • Attack 2b: The kernel-return attack was demonstrated with SMEP disabled after arranging for the victim to resume inside the kernel following a blocking system call.The attack therefore depends on a machine without SMEP enabled.
  • Attack 2c: A process-boundary attack would require victim-gadget discovery, possible ASLR recovery, synchronization, and cache eviction, and the paper reports no proof of concept.Triggering victim operations, such as server connections, could simplify synchronization.

6 SpectreRSB Atack 3: Attacks on SGX

The paper investigates SpectreRSB attacks against SGX compartments by polluting the RSB to induce misspeculation inside an enclave. The proof-of-concept attack succeeds on fully patched machines and bypasses software and microcode defenses.

  • The attack uses untrusted user code or a malicious OS to pollute the RSB with a payload gadget address before enclave misspeculation.The gadget may reside in untrusted user code because user code and SGX enclaves share the same address space.
  • The proof-of-concept places an unmatched return inside the enclave, while timing or blocking-call strategies could induce the required scheduling behavior elsewhere.
  • The attack succeeds on fully patched machines and bypasses Retpoline, Intel microcode patches, and RSB refilling.It avoids Retpoline because it uses no indirect jumps, and it avoids RSB refilling because no kernel mode switch occurs.
  • SGX therefore remains vulnerable to SpectreRSB even when software and microcode defenses are deployed.

7 Potential Attack 4: From user to Kernel

The paper examines a potential SpectreRSB attack that pollutes the RSB in user code and triggers an unmatched return in the kernel. The attack can execute speculatively in supervisor mode, but its demonstrated form depends on an unpatched machine and several difficult conditions.

  • A polluted RSB can redirect an unmatched kernel return into speculative execution while the kernel address space remains mapped.
  • The proof-of-concept attack works on an unpatched machine or one without RSB refilling, including the tested Xeon machine.It does not work on patched Skylake+ processors because of RSB refilling.
  • SMEP prevents speculative returns to user-space gadgets, so the demonstrated attack required SMEP to be disabled.A kernel-space gadget or a PhysMap address was discussed as an alternative, but most Linux distributions disable PhysMap execution.
  • The attack also assumes that the attacker can determine the address of the top of the kernel stack to flush it and enlarge the speculation window.

8 Discussion and Mitigations

The discussion shows that SpectreRSB can operate across address spaces and execution threads, while SGX attacks bypass existing defenses. The paper proposes broader RSB refilling and additional RSB-focused microcode protections.

  • None of the Intel microcode patches appear to restrict speculation through the RSB, unlike Retpoline, which addresses branch-target-buffer poisoning rather than returns.
  • The SGX attack bypasses all known defenses, including RSB refilling, and remains an open vulnerability on SGX systems.
  • Kernel-targeting attacks can defeat KPTI and Retpoline in principle, but RSB refilling on Intel Skylake+ stops the demonstrated Attack 4 and other practical complications remain.The attack also faces SMEP and kernel-stack-address requirements.
  • The paper recommends RSB refilling on all processors, including at SGX enclave entry, and extending Intel microcode protection beyond the branch predictor.

9 Related Work

The related-work discussion reviews defenses and attacks surrounding speculative side channels. It argues that cache-focused defenses do not provide a principled solution because attacks can occur within one process or use alternative side channels.

  • Cache defenses are reviewed because caches are the primary channel used by Meltdown and Spectre to communicate privileged data.
  • Securing caches may protect published proof-of-concept attacks, but speculative data can be communicated through other side channels.
  • Software side-channel defenses are unlikely to provide beneficial protection when attackers can write leakage-generating code or identify unintended gadgets.
  • Randomization and relaxed cache inclusion do not help attacks launched within the same process, including SpectreRSB attacks 1 and 3.
  • The discussion places SpectreRSB alongside SGXPECTRE and BranchScope as attacks that use speculative execution or predictor pollution through structures beyond the traditional branch-target predictor.

10 Concluding Remarks

SpectreRSB uses the Return Stack Buffer rather than the branch predictor to enable multiple speculation-attack vectors and bypass published Spectre defenses. The paper argues that existing patches are ad hoc and recommends broader deployment of RSB refilling while pursuing safer speculative-execution designs.

  • SpectreRSB is triggered by the Return Stack Buffer rather than the branch predictor and enables attacks within processes, against SGX, against the kernel, and across threads and processes.The authors characterize SpectreRSB as a highly dangerous vulnerability because it bypasses all published Spectre defenses.
  • SpectreRSB bypasses all published defenses against Spectre.
  • RSB refilling interferes with SpectreRSB attacks that experience at least one user-to-kernel mode switch.The paper recommends deploying this patch across all processor generations, not only Skylake and newer processors.
  • The authors describe current patches as ad hoc and state that future attack vectors will continue to emerge.They argue that future CPUs could retain speculation while separating speculative data from committed data to close leakage channels.
Loading 1807.07940v1…