Source-linked AI summary
Speculative Buffer Overflows: Attacks and Defenses
Vladimir Kiriansky, Carl Waldspurger
TL;DR
Speculative stores can create buffer overflows that enable data and control-flow attacks, including local and remote confidentiality, integrity, and availability attacks. The paper analyzes these risks and defenses, proposing software mitigations and SLoth microarchitectural mechanisms to reduce speculative store-to-load forwarding opportunities.
Problem
Speculative buffer overflows create a new speculative-execution attack class in which speculative stores can break type and memory safety, posing risks beyond existing Spectre-v1 analyses.
Method
The paper analyzes relevant hardware features and attacks, then discusses software defenses and proposes SLoth mechanisms that reduce speculative store-to-load forwarding opportunities for attackers.
Results
The preliminary threat analysis indicates that attackers may mount local and remote confidentiality, integrity, and availability attacks, including attacks that bypass recommended mitigations for previous speculative-execution attacks.
Takeaways & Limitations
Speculative buffer overflows require broader vulnerable-software analysis and generic defense-in-depth mitigations, while hardware may be able to address Spectre1.1 completely with good performance.
Takeaways & Limitations
The proposed software and hardware mitigations have not yet been evaluated for performance impact.
Abstract
from arXiv · showhide
Practical attacks that exploit speculative execution can leak confidential information via microarchitectural side channels. The recently-demonstrated Spectre attacks leverage speculative loads which circumvent access checks to read memory-resident secrets, transmitting them to an attacker using cache timing or other covert communication channels. We introduce Spectre1.1, a new Spectre-v1 variant that leverages speculative stores to create speculative buffer overflows. Much like classic buffer overflows, speculative out-of-bounds stores can modify data and code pointers. Data-value attacks can bypass some Spectre-v1 mitigations, either directly or by redirecting control flow. Control-flow attacks enable arbitrary speculative code execution, which can bypass fence instructions and all other software mitigations for previous speculative-execution attacks. It is easy to construct return-oriented-programming (ROP) gadgets that can be used to build alternative attack payloads. We also present Spectre1.2: on CPUs that do not enforce read/write protections, speculative stores can overwrite read-only data and code pointers to breach sandboxes. We highlight new risks posed by these vulnerabilities, discuss possible software mitigations, and sketch microarchitectural mechanisms that could serve as hardware defenses. We have not yet evaluated the performance impact of our proposed software and hardware mitigations. We describe the salient vulnerability features and additional hypothetical attack scenarios only to the detail necessary to guide hardware and software vendors in threat analysis and mitigations. We advise users to refer to more user-friendly vendor recommendations for mitigations against speculative buffer overflows or available patches.
1 Introduction
The paper introduces Spectre1.1, which uses speculative stores to create arbitrary speculative writes and execution, extending risks beyond Spectre1.0’s load-based attacks. It also presents Spectre1.2, which can bypass read-only protections, while existing software defenses remain incomplete.
- New attack variants: Spectre1.1 uses speculative out-of-bounds stores to modify data or code pointers during speculative execution.The vulnerable store can provide an attacker-controlled arbitrary write without architectural effects.
- New attack variants: Control-flow attacks can redirect speculative execution, bypass fences, and support alternative ROP-based payloads.A speculative overwrite of a return address can jump over a fence and reach a transmission gadget.
- New attack variants: Spectre1.1 can temporarily overwrite data used by Spectre1.0 gadgets, defeating data-dependent truncation by changing an array base or length.This restores arbitrary read access within the speculative gadget.
- New attack variants: Spectre1.2 allows speculative stores to overwrite read-only data, code pointers, and control-flow metadata, undermining sandboxing based on read-only memory.The variant depends on lazy enforcement of read/write page-table protections.
- Contributions and defenses: No effective generic static analysis or compiler instrumentation currently detects or mitigates Spectre1.1, while existing Spectre1.0 mitigations cover only subsets of vulnerable code.Manual defenses may require developers to reason about mitigation necessity, potentially prolonging exposure.
- Contributions and defenses: The paper proposes analyzing hardware features, strengthening software defenses, and developing SLoth hardware mechanisms that reduce speculative store-to-load forwarding opportunities.Its preliminary threat analysis indicates possible local and remote confidentiality, integrity, and availability attacks.
2 Hardware and Software Background
The paper explains how speculative execution, out-of-order memory behavior, and delayed protection checks create the conditions exploited by Spectre variants. In particular, large speculative windows and speculative store-to-load forwarding allow attack effects to influence later operations.
- Speculation mechanisms: Modern processors rely on branch, exception, and address speculation to improve performance, creating distinct speculative-execution vulnerability classes.Spectre variants 1 and 2 use branch speculation, variant 3 uses exception speculation, and variant 4 uses address speculation.
- Memory speculation: Speculative store-to-load forwarding lets a load use prior store data once the store address and data are available.The load must be no larger than the store, the store must be youngest at that address, and physical addresses must fully match.
- Speculative window: Speculative windows are bounded by in-flight instruction capacity and branch-resolution delay, but current processors provide substantial capacity.Intel Skylake’s 224-entry ROB gives each SMT thread roughly 100 typical instructions.
- Speculative window: Superscalar execution can run attack-gadget instructions before a bounds-check branch resolves.Intel Skylake can execute multiple arithmetic instructions, branches, loads, and a store in one cycle.
- Cache side channels: Non-blocking caches preserve speculative memory requests that miss in L1, allowing repeated executions to reuse cached values for side-channel transmission.The a[b[i]*512] gadget first caches the secret and later uses it to access a secret-dependent cache line.
3 Speculative Buffer Overflows
Speculative buffer overflows let attackers execute arbitrary untrusted code inside the victim domain. The paper dissects the mechanism and considers software and hardware defenses, including repurposed classic buffer-overflow mitigations.
- Speculative Buffer Overflows: Speculative buffer overflows enable arbitrary speculative execution of attacker-controlled code within the victim domain.The paper presents this as the central attack capability of the new vulnerability class.
- Speculative Buffer Overflows: The paper analyzes the attack from source code through assembly and RISC micro-ops, including requirements for longer speculative windows.It also discusses manual mitigations and adapting classic buffer-overflow defenses.
3.1 Spectre1.1 Assembly and Micro-ops
The Spectre1.1 demonstration begins with a delayed bounds check, performs a speculative store to a return address, and uses store-to-load forwarding to redirect a return into a ROP path. The attack was validated on ARM and Intel x86 processors, though exposition is limited to x86-64 assembly.
- Validation scope: The attack was validated on ARM and Intel x86 processors, while the paper presents its exposition in x86-64 assembly.The reported testing and exposition scopes differ by architecture.
- Assembly path: The attack uses a bounds check whose branch is predicted not taken while its comparison waits on a non-cached value.The correct path later retires with the branch taken.
- Execution paths: The listings distinguish the normal speculative path from the attack path, where execution is resteered after the speculative overwrite.The attack path is described as occurring before the branch resolves and while the return target is redirected.
- Micro-ops: Store-to-load forwarding supplies the overwritten return address to retq, whose load and indirect branch resteer execution to the ROP payload.The micro-op breakdown represents this as LDA followed by JR.
3.2 Spectre1.1 Attack Preconditions
Spectre1.1 attacks require speculation to remain active long enough for either a corrupted indirect control transfer or a reachable Spectre1.0 sequence. The necessary window depends on unresolved branches and the mitigation strategy used.
- The most vulnerable branches depend on previous long-latency operations, including dependent non-cached memory references such as array->length.
- Code-pointer attacks must fit the payload, intervening instructions, and a corrupted indirect branch within the speculative window.The attacked indirect branch is typically a ret whose normal prediction must be overridden using corrupt data.
- Data attacks must keep speculation active until a target Spectre1.0 sequence is reached normally.A speculation barrier such as lfence would block this attack, but data-dependent mitigations can instead be bypassed by overwriting an array base or length.
3.3 Spectre1.1 Manual Defenses
Manual defenses adapt classic bounds checks, fences, masking, initialization, and iterator clamping to speculative stores. Their practical challenges include performance costs, compiler dependence, broader analysis requirements, and possible violations of program invariants.
- Manual Spectre1.1 mitigation requires analyzing many more potentially vulnerable locations than Spectre1.0 mitigation.The goal is security with good performance, but the larger search space complicates manual placement.
- Speculation Fences: Fences can order stores after resolved branches, but they impose high performance costs on unaffected paths.On x86, lfence is documented as serializing; vendors should ensure stores or all instructions are ordered by equivalent fences.
- Coarse Masking: Coarse power-of-two masking may fail to protect stores unless memory regions are padded, incurring internal fragmentation overhead.Vulnerable locations that break type safety may remain reachable when object layouts do not align with exact powers of two.
- Data-dependent Exact Masking: Data-dependent index truncation can protect stores without stopping speculation, but safe implementation requires compiler- and optimization-aware assembly sequences.The compiler may replace a required conditional move with an unsafe branch, and behavior depends on optimization and profile-guided optimization.
- Congruent Branch TOCTOU: Speculative execution can invalidate compiler optimizations based on congruent branches and correct-path assumptions.Impossible paths may invalidate buffer, size, index, and loop-count invariants; ghosts can enable arbitrary speculative reads, writes, and code execution.
- Congruent Branch TOCTOU: All functions should be analyzed for vulnerable patterns because ghosts and halos can arise beyond gateway functions handling untrusted inputs.Iterator clamping can help, but it must preserve invariants such as capacity(a[b[i]]) > len(c[i]).
3.4 Fortified Classic Buffer Overflow Mitigations
The paper strengthens classic buffer-overflow defenses against speculative attacks through speculation-safe control-flow and memory-integrity checks, return protections, and hardware support. It also identifies important boundaries: read-only page protections and ASLR are insufficient against some variants.
- Code-pointer protections such as CFG can be strengthened by performing target validation without conditional branches and by using poisoned write pointers.
- Arithmetic guards can create non-canonical addresses that poison indirect transfers or write addresses instead of relying on conditional branches.Removing never-taken branches may improve prediction accuracy and could benefit security and performance overall, although attackers might benefit from more predictable behavior.
- Read-only page-table protections for CFG metadata are insufficient against Spectre1.2 and must be strengthened.Speculative stores may overwrite read-only code, although the paper does not expect those results to reach instruction fetch.
- Return Protections: Return protections can combine canary-based checks with hardware defenses that restrict RSB mispredictions or speculative store forwarding to ret.The canary variation preserves the current stack layout and return address for backtraces, while compiler optimization may elide canaries.
- ASLR is the only currently available generic mitigation for speculative buffer overflows, but it is the weakest classic buffer-overflow mitigation.It mitigates both code and data attacks yet can be defeated by information leaks and side channels against branch history or page-table walkers.
- Memory Protection Keys: Speculative code-execution gadgets can disable memory protection keys before reading secrets, so protections around wrpkru require stronger architectural treatment.Making wrpkru internally include lfence is proposed to prevent speculative misuse.
4 Hardware Mitigations
The paper sketches the SLoth family of hardware mitigations, which constrain speculative store-to-load forwarding through progressively different performance and complexity trade-offs.
- SLoth mitigations defend against Spectre1.1 by constraining store-to-load forwarding.The family includes store-to-load blocking, lazy forwarding, and frozen forwarding.
- SLoth Bear blocks forwarding from speculative stores or to speculative loads and could support rapid protection for unpatched software.Its implementation in microcode remains unknown, and the approach may impose high overheads on register spills and C++ member-variable accesses.
- SLoth uses compiler-marked instructions as forwarding candidates, localizing hardware changes to the load-store unit.The paper describes its low complexity and small trusted computing base as attractive; compiler co-design could achieve optimal performance.
- The paper frames higher-performance hardware as potentially justifiable when software mitigations are error-prone alternatives.This trade-off is presented as a motivation for accepting greater hardware complexity.
- Arctic SLoth dynamically detects store-load pairs eligible for forwarding, potentially requiring stronger address speculation and full physical address tags.These requirements may increase CPU complexity, power, and area.
5 Speculative Attack Payloads
Speculative attack payloads combine vulnerable code and data with secrets, attacker-controlled payload parameters, and executable gadgets to influence microarchitectural state.
- Speculative buffer overflows permit arbitrary speculative code execution, but payload fragments are short-lived and limited to roughly a hundred instructions.The paper discusses hypothetical payloads that escape the weak sandbox of out-of-order execution.
- The threat analysis preliminarily indicates possible local and remote confidentiality, integrity, and availability attacks.The authors advise broader vulnerable-software analysis and generic defense-in-depth mitigations.
- The analysis assumes attacker-controlled inputs reach Spectre1.x victims that process requests and may respond, with high-value secret-holding systems as the primary concern.Examples include credentials and private keys; systems executing untrusted code are identified as especially exposed.
- An attack combines vulnerable code, vulnerable data, sensitive data, speculative payload data, and speculative payload code.The attacker must reach a vulnerability that is not resolved quickly and control payload parameters and executable gadgets.
- Spectre1.1 concerns out-of-bounds or uninitialized writes, while Spectre1.0 concerns reads and Spectre4 concerns shadow or alias address speculation.The paper distinguishes speculative write, read, shadow, and alias mechanisms as different vulnerability classes.
- Payloads may use existing code, ROP gadgets, and stack pivoting, while some speculative function-pointer attacks also enable arbitrary code execution.The text notes that SLoth does not protect against every related speculative execution path.
- Stateful channels receive secrets through footprint timing, whereas stateless channels rely on throughput timing.Secret access and transmission can use dependent memory accesses, control-dependent selection, or data-dependent variable latency, and attacks can compose multiple stages.
5.4 Receiver (Non-Speculative Code)
Non-speculative receivers recover speculative effects through timing channels, but reduced timer precision mainly slows cache-timing attacks rather than preventing them.
- Receiving a secret is generally non-speculative, although sandboxed or virtualized timing may be slowed by coarsened timers.
- Browser timer reduction changes performance.now() to 100 μs granularity, obscuring events such as approximately 100 ns cache misses.
- Timer coarsening only slows attacks; requesting multiple cache lines per measured bit amplifies timing differences but increases cache-footprint pressure.Evictions may occur as the amplification factor grows, yet mostly resident versus non-resident lines can retain a strong signal.
- Stateful receivers can use cache lines, branch predictors, address-translation structures, and other microarchitectural resources as footprints.
- Flush+reload requires shared cache lines, whereas prime+probe can use congruent lines without memory shared with the victim.The paper also identifies evict+reload and flush+flush as related cache-timing variants.
- Careful partitioning of microarchitectural state can prevent footprint attacks, including speculative and non-speculative variants.DAWG is cited as a design that partitions caches, TLBs, PTE caches, and related structures.
5.6 Throughput Timing Side Channels
Throughput-timing channels infer speculative activity from contention or self-interference in shared resources, extending beyond cache footprints to local and remote attack settings.
- Throughput channels require concurrent transmission and reception, measuring contention in cache, out-of-order execution, or system resources.
- An attacker can measure victim throughput, such as the number of executed macro-operations, after secret-dependent microarchitectural state is influenced.
- Traditional SMT throughput attacks require SMT sharing and are generally unsuitable for cross-VM cloud attacks, though some burstable instances may permit such sharing.
- Measuring an SMT peer is plausible in trusted-domain cloud instances but requires detecting how connections map to processing threads.
- Victim self-interference is the most general method and can support sandbox escapes or remote attacks with only connection persistence.
- Potential modulation targets include MSHRs, variable-latency ALUs, AVX2 frequency behavior, and RDRAND contention.These mechanisms alter throughput through memory-level parallelism, instruction latency, frequency, or generator availability.
- The examples suggest modulation opportunities are pervasive, making prevention through SLoth preferable to detecting every bad behavior.
- Cache eviction can support integrity attacks, including hypothetical RowHammer-style attacks that SLoth is intended to prevent through Spectre1.1 protection.
6 Conclusions
The paper identifies speculative stores as a source of speculative buffer overflows that create significant new risks, including arbitrary speculative execution and attacks that bypass earlier software mitigations. It argues that hardware can address this attack class while preserving speculative-execution performance, although proposed mitigation performance has not yet been evaluated.
- 6 Conclusions: Speculative stores create buffer overflows that introduce significant risks, including arbitrary speculative execution and local or remote attacks without Spectre1.0 gadgets.These attacks can also bypass recommended software mitigations for earlier speculative-execution attacks.
- 6 Conclusions: Speculative-execution bugs resemble known memory- and type-safety failures, motivating stronger generic protections against speculative and classic buffer overflows.The paper notes increased acceptance of security overheads because of heightened public awareness of Spectre-related attacks.
- 6 Conclusions: The authors believe hardware can completely address Spectre1.1 speculative buffer overflows without adding to the classic buffer-overflow patch burden.They further state that future systems should close this vector with good performance.
- 6 Conclusions: The paper expects secure hardware and software to retain speculative-execution performance benefits while acknowledging that short-term patches may remain necessary.The proposed software and hardware mitigations' performance impact is not evaluated in the supplied passages.