Speculative Buffer Overflows: Attacks and Defenses

1 Speculative Buffer Overflows: Attacks and DefensesVladimir Attacks that exploit Speculative execution can leakconfidential information via microarchitectural side chan-nels. The recently-demonstrated Spectre Attacks leveragespeculative loads which circumvent access checks to readmemory-resident secrets, transmitting them to an attackerusing cache timing or other covert communication , a new Spectre-v1 variant thatleverages speculativestoresto createspeculative Buffer over-flows. Much like classic Buffer overflows, Speculative out-of-bounds stores can modify data and code pointers. Data-valueattacks can bypass some Spectre-v1 mitigations, either di-rectly or by redirecting control flow. Control-flow attacksenable arbitrary Speculative code execution, which can by-pass fence instructions and all other software mitigationsfor previous Speculative -execution Attacks .

2 It is easy to con-struct return-oriented-programming (ROP) gadgets that canbe used to build alternative attack also : on CPUs that do not enforceread/write protections, Speculative stores can overwriteread-onlydata and code pointers to breach highlight new risks posed by these vulnerabilities,discuss possible software mitigations, and sketch microarchi-tectural mechanisms that could serve as hardware have not yet evaluated the performance impact of ourproposed software and hardware mitigations. We describethe salient vulnerability features and additional hypothet-ical attack scenarios only to the detail necessary to guidehardware and software vendors in threat analysis and mitiga-tions. We advise users to refer to more user-friendly vendorrecommendations for mitigations against Speculative bufferoverflows or available IntroductionWe dub the primary new attack mechanism described in (CVE-2018-3693, bounds check bypass onstores), to distinguish it from the original Speculative execu-tion attack variant 1 (CVE-2017-5753), which we refer to We minor variant in thevariant 1 family, since it uses the same opening in the specu-lative execution window conditional branch : Bounds Check Bypass on LoadsAllowing execution past conditional branches is the mostimportant performance optimization employed by specu-lative out-of-order processors essentially every modernhigh-performance CPU.

3 Recently, multiple independent re-searchers have disclosed ways for attackers to leak sensitivedata across trust boundaries by exploiting Speculative execu-tion [22,35,39]. Using Speculative execution, an attacker isable to influence code in the victim s domain to access andtransmit a chosen secret [22, 35].The transmission channel in current proof-of-concept at-tacks uses microarchitectural cache state a channel avail-able to speculatively-executed instructions. Cache tag statewas a previously-known channel for transmitting informa-tion in more limited scenarios side channels (during execu-tion of cryptographic software operating on a secret [7]), andcovert channels (where a cooperating transmitter is used).The , as well as currently de-ployed mitigations, target sequences like Listing 1. Since aspeculative out-of-order processor may ignore the boundscheck on line 1, an attacker-controlled valuexis not con-strained bylenb, the length of arrayb.

4 Asecret valuead-dressable asb[x]can therefore be used to influence theindex of a dependent load from arrayainto the the simplest attack scenario, the attacker also has accessto arraya, and flushes it from the cache before executing thevictim code [59]. The Speculative attack leaves a footprint inthe cache, and the attacker measures each cache line ofatodetermine which one has the lowest access time inferringthe secret value from the address of the fastest line. Genericmitigations its variants, such as re-stricting shared memory or reducing timer precision, havebeen limited to this particular ex-filtration (x <lenb)2returna[b[x]*512];Listing : Bounds Check Bypass (on Loads). Speculative secret access via attacker-controlledx, andindirect-load transmission gadget using attacker-controlledcache state for (y <lenc)4c[y] = z;Listing : Bounds Check Bypass (on Stores).

5 Arbitrary Speculative write with attacker-controlledy, andattacker-controlled or known [ ] 10 Jul : Bounds Check Bypass on StoresCode vulnerable shown in Listing 2. Duringspeculative execution, the processor may ignore the boundscheck on line 3. This provides an attacker with the full powerof an arbitrary write. While this is only aspeculativewrite,which leaves no architecturally-visible effects, it can still leadto information disclosure via side a simple proof-of-concept attack, supposec[y]pointsto the return address on the stack, andzcontains the addressof line 2 in Listing 1. During Speculative execution of a func-tion return, execution will be resteered to the transmissiongadget, as previously described. Note that even if a fenceinstruction ( ,lfenceorcsdb[47]) is added betweenlines 1 and 2 to mitigate , an attacker cansimply adjustzto jump over the fence.

6 Return-oriented-programming (ROP) techniques can also be used to buildalternative attack payloads, as described in Section a Speculative data attack, an attacker can (temporarily)overwrite data used by a Per-formant gadget mitigations use data-dependent truncation( ,x &= (lenb-1)) rather than fences. An attacker re-gains arbitrary read access by overwriting either the base ofarrayb(line 2), or its length,lenb(line 1). : Read-only Protection , aka Meltdown [39], relies on lazy enforcementof User/Supervisor protection flags for page-table entries(PTEs). The same mechanism can also be used to bypass theRead/Write PTE flags. We , a minor vari-ant of Spectre-v1 which depends on lazy PTE enforcement,similar to Spectre-v3. In , speculativestores are allowed to overwriteread-onlydata, code point-ers, and code metadata, including vtables, GOT/IAT, andcontrol-flow mitigation metadata.

7 As a result, sandboxingthat depends on hardware enforcement of read-only memoryis rendered Current Software DefensesCurrently, no effective static analysis or compiler instru-mentation is available to generically detect or Manual mitigations only veryspecific cases in trusted code ( , in the Linux kernel), wherea load is used for further indirect memory generic mitigations been pro-ductized, such as compiler analysis for C [46], they identifyonly a subset of vulnerable indirect-load code instances. Acomprehensive compiler-based mitigation approach usingspeculative load hardening [9] has been proposed, but incursa high performance cost. Generic mitigations for JavaScript, as in V8 [18] and Chakra [43], pro-tect only bounds checks for we must rely on software mitigations that require devel-opers to manually reason about the necessity of mitigations,we may face decades of Speculative -execution Attacks .

8 Thelimited success at educating software developers for the pastthirty years since the 1988 public demonstration of classicbuffer overflows is a cautionary guide. The silver lining isthat the same coding patterns are vulnerable to speculativebuffer overflows. A good first step toward preventing themwould be to strengthen existing checks against stack over-flows, heap overflows, integer overflows, Contributions and OrganizationWe make several key contributions: We introducespeculative Buffer overflows attacksbased on Speculative stores that break type and mem-ory safety during Speculative execution. We analyze salient hardware features to guide possiblesoftware and hardware mitigations. We present new risks posed byimpossible paths,ghosts,andhalos, and discuss possible Defenses . We propose theSLothfamily of microarchitecturalmechanisms to defend against Speculative Buffer over-flow Attacks by reducing Speculative store-to-load for-warding opportunities for attackers.

9 We present a preliminary threat analysis that indicatesattackers may be able to mount both local and remoteconfidentiality, integrity, and availability the next section, we provide relevant hardware and soft-ware background related to Speculative execution. Section 3presents a detailed analysis of Speculative Buffer overflows,including both vulnerability mechanisms and possible soft-ware mitigations. We introduce our SLoth family of hardwaremitigations in Section 4. Section 5 focuses on threat analysisof payloads leading to remote confidentiality Attacks and lo-cal integrity Attacks . Finally, we summarize our conclusionsand highlight opportunities for future work in Section Hardware and Software BackgroundWe first review relevant Speculative -execution performanceoptimizations of modern out-of-order superscalar CPUs inSection We then describe the hardware features salientto our minor variants in Section , and Sec-tion Section discusses further hard-ware and software features that impact exploitation Speculative Out-Of-Order ExecutionSpeculative-execution hardware vulnerabilities are the re-sult of classic computer architecture optimizations from pre-Internet-era design decisions.

10 There are three main optimiza-tions that depend on Speculative execution: branch specu-lation, exception speculation, and address speculation. Thecurrently-disclosed Spectre variants 1 (bounds check bypass)and 2 (branch target injection) use branch speculation, vari-ant 3 (rogue load) uses exception speculation, and variant 4( Speculative store bypass) is one case of address speculation takes advantage of temporal and spa-tial locality in program control flow, and for most programsachieves low branch misprediction rates; high-performancemicroarchitectures speculate through multiple branches. Ex-ception speculation assumes that most operations, , loads,do not need to trap. Address speculation is used for mem-ory disambiguation, when loads are assumed not to conflictwith earlier stores to unknown addresses. Loads are alsospeculated to hit L1 caches, and immediately-dependent in-structions may observevalue speculationwith the value 0(before mini-replay [22,60]).