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.

2 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 . 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.

3 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.

4 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. 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.

5 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. 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].

6 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).

7 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.

8 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 . 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.

9 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.

10 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.