[Paper Review] Speculative Buffer Overflows: Attacks and Defenses

Vladimir Kiriansky, Carl A. Waldspurger|arXiv (Cornell University)|Jul 10, 2018

Security and Verification in Computing22 references127 citations

TL;DR

The paper introduces speculative buffer overflows (Spectre1.1 and Spectre1.2), analyzes their hardware/software mechanisms, and proposes the SLoth family of hardware mitigations to curb speculative store-to-load forwarding, along with manual software defenses.

ABSTRACT

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.

Motivation & Objective

• Introduce speculative buffer overflows as attacks that break memory safety during speculative execution.
• Analyze hardware features enabling these attacks to guide mitigations.
• Propose software mitigations and hardware solutions (SLoth) to defend against speculative buffer overflows.
• Discuss threat models and potential payloads to inform defense-in-depth strategies.

Proposed method

• Describe Spectre1.1 and Spectre1.2 attack mechanisms and required speculative execution windows.
• Analyze store-to-load forwarding and data/tlb speculation as foundational hardware features.
• Review and adapt classic buffer overflow mitigations to speculative contexts (e.g., speculation fences, masking, and TOCTOU defenses).
• Propose the SLoth family (Store-to-Load Blocking, Lazy Forwarding, Frozen Forwarding) as hardware mitigations.
• Outline risk scenarios, including ghosts/halos and potential payloads, to guide threat analysis and mitigation design.

Experimental results

Research questions

• RQ1 What new capabilities do Spectre1.1 and Spectre1.2 enable beyond Spectre1.0?
• RQ2 How can hardware structures like store buffers, MSHRs, and TLB speculation be exploited by speculative buffer overflows?
• RQ3 What software and hardware mitigations can effectively prevent speculative buffer overflows without prohibitive performance penalties?
• RQ4 What are the realistic threat models and potential attack payloads stemming from speculative buffer overflow vulnerabilities?

Key findings

• Spectre1.1 enables arbitrary speculative writes via speculative stores, potentially bypassing prior mitigations.
• Spectre1.2 can overwrite read-only data and code pointers by exploiting lazy enforcement of protections, undermining sandboxing.
• Manual and coarse mitigations exist but are often expensive or incomplete; data-dependent exact masking and flow-sensitive defenses are discussed.
• A suite of hardware mitigations (SLoth family) is proposed to constrain store-to-load forwarding with varying complexity and performance impact.
• Attack payload discussions indicate both local and remote confidentiality, integrity, and availability risks under speculative execution threats.
• The paper emphasizes the need for defense-in-depth and vendor guidance pending performance evaluations of mitigations.