Transcription

Spectre Attacks: Exploiting Speculative Execution3Paul Kocher1 , Jann Horn2 , Anders Fogh3 , Daniel Genkin4 ,Daniel Gruss5 , Werner Haas6 , Mike Hamburg7 , Moritz Lipp5 ,Stefan Mangard5 , Thomas Prescher6 , Michael Schwarz5 , Yuval Yarom81 Independent (www.paulkocher.com), 2 Google Project Zero,G DATA Advanced Analytics, 4 University of Pennsylvania and University of Maryland,5 Graz University of Technology, 6 Cyberus Technology,7 Rambus, Cryptography Research Division, 8 University of Adelaide and Data61Abstract—Modern processors use branch prediction and speculative execution to maximize performance. For example, if thedestination of a branch depends on a memory value that is in theprocess of being read, CPUs will try to guess the destination andattempt to execute ahead. When the memory value finally arrives,the CPU either discards or commits the speculative computation.Speculative logic is unfaithful in how it executes, can access thevictim’s memory and registers, and can perform operations withmeasurable side effects.Spectre attacks involve inducing a victim to speculativelyperform operations that would not occur during correct programexecution and which leak the victim’s confidential information viaa side channel to the adversary. This paper describes practicalattacks that combine methodology from side channel attacks,fault attacks, and return-oriented programming that can readarbitrary memory from the victim’s process. More broadly, thepaper shows that speculative execution implementations violatethe security assumptions underpinning numerous software security mechanisms, including operating system process separation,containerization, just-in-time (JIT) compilation, and countermeasures to cache timing and side-channel attacks. These attacksrepresent a serious threat to actual systems since vulnerablespeculative execution capabilities are found in microprocessorsfrom Intel, AMD, and ARM that are used in billions of devices.While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processordesigns as well as updates to instruction set architectures (ISAs)to give hardware architects and software developers a commonunderstanding as to what computation state CPU implementations are (and are not) permitted to leak.I. I NTRODUCTIONComputations performed by physical devices often leaveobservable side effects beyond the computation’s nominaloutputs. Side-channel attacks focus on exploiting these sideeffects to extract otherwise-unavailable secret information.Since their introduction in the late 90’s [43], many physicaleffects such as power consumption [41, 42], electromagneticradiation [58], or acoustic noise [20] have been leveraged toextract cryptographic keys as well as other secrets.Physical side-channel attacks can also be used to extractsecret information from complex devices such as PCs andmobile phones [21, 22]. However, because these devicesoften execute code from a potentially unknown origin, theyface additional threats in the form of software-based attacks,which do not require external measurement equipment. Whilesome attacks exploit software vulnerabilities (such as bufferoverflows [5] or double-free errors [12]), other software attacksleverage hardware vulnerabilities to leak sensitive information.Attacks of the latter type include microarchitectural attacksexploiting cache timing [8, 30, 48, 52, 55, 69, 74], branchprediction history [1, 2], branch target buffers [14, 44] or openDRAM rows [56]. Software-based techniques have also beenused to mount fault attacks that alter physical memory [39] orinternal CPU values [65].Several microarchitectural design techniques have facilitatedthe increase in processor speed over the past decades. One suchadvancement is speculative execution, which is widely usedto increase performance and involves having the CPU guesslikely future execution directions and prematurely executeinstructions on these paths. More specifically, consider anexample where the program’s control flow depends on anuncached value located in external physical memory. As thismemory is much slower than the CPU, it often takes severalhundred clock cycles before the value becomes known. Ratherthan wasting these cycles by idling, the CPU attempts to guessthe direction of control flow, saves a checkpoint of its registerstate, and proceeds to speculatively execute the program on theguessed path. When the value eventually arrives from memory,the CPU checks the correctness of its initial guess. If theguess was wrong, the CPU discards the incorrect speculativeexecution by reverting the register state back to the storedcheckpoint, resulting in performance comparable to idling.However, if the guess was correct, the speculative executionresults are committed, yielding a significant performance gainas useful work was accomplished during the delay.From a security perspective, speculative execution involvesexecuting a program in possibly incorrect ways. However,because CPUs are designed to maintain functional correctnessby reverting the results of incorrect speculative executions totheir prior states, these errors were previously assumed to besafe.A. Our ResultsIn this paper, we analyze the security implications of suchincorrect speculative execution. We present a class of microarchitectural attacks which we call Spectre attacks. At a highlevel, Spectre attacks trick the processor into speculativelyexecuting instruction sequences that should not have beenexecuted under correct program execution. As the effects ofthese instructions on the nominal CPU state are eventually

reverted, we call them transient instructions. By influencingwhich transient instructions are speculatively executed, we areable to leak information from within the victim’s memoryaddress space.We empirically demonstrate the feasibility of Spectre attacksby exploiting transient instruction sequences to leak information across security domains both from unprivileged nativecode, as well as from portable JavaScript code.Attacks using Native Code. As a proof-of-concept, wecreate a simple victim program that contains secret data withinits memory address space. Next, we search the compiledvictim binary and the operating system’s shared libraries forinstruction sequences that can be used to leak informationfrom the victim’s address space. Finally, we write an attackerprogram that exploits the CPU’s speculative execution featureto execute the previously-found sequences as transient instructions. Using this technique, we are able to read memory fromthe victim’s address space, including the secrets stored withinit.Attacks using JavaScript and eBPF. In addition to violatingprocess isolation boundaries using native code, Spectre attackscan also be used to violate sandboxing, e.g., by mountingthem via portable JavaScript code. Empirically demonstratingthis, we show a JavaScript program that successfully readsdata from the address space of the browser process runningit. In addition, we demonstrate attacks leveraging the eBPFinterpreter and JIT in Linux.B. Our TechniquesAt a high level, Spectre attacks violate memory isolation boundaries by combining speculative execution withdata exfiltration via microarchitectural covert channels. Morespecifically, to mount a Spectre attack, an attacker starts bylocating or introducing a sequence of instructions within theprocess address space which, when executed, acts as a covertchannel transmitter that leaks the victim’s memory or registercontents. The attacker then tricks the CPU into speculativelyand erroneously executing this instruction sequence, therebyleaking the victim’s information over the covert channel.Finally, the attacker retrieves the victim’s information overthe covert channel. While the changes to the nominal CPUstate resulting from this erroneous speculative execution areeventually reverted, previously leaked information or changesto other microarchitectural states of the CPU, e.g., cachecontents, can survive nominal state reversion.The above description of Spectre attacks is general, andneeds to be concretely instantiated with a way to induceerroneous speculative execution as well as with a microarchitectural covert channel. While many choices are possiblefor the covert channel component, the implementations described in this work use cache-based covert channels [64],i.e., Flush Reload [74] and Evict Reload [25, 45].We now proceed to describe our techniques for inducingand influencing erroneous speculative execution.Variant 1: Exploiting Conditional Branches. In this variantof Spectre attacks, the attacker mistrains the CPU’s branchpredictor into mispredicting the direction of a branch, causingthe CPU to temporarily violate program semantics by executing code that would not have been executed otherwise. As weshow, this incorrect speculative execution allows an attacker toread secret information stored in the program’s address space.Indeed, consider the following code example:if (x array1 size)y array2[array1[x] * 4096];In the example above, assume that the variable x containsattacker-controlled data. To ensure the validity of the memoryaccess to array1, the above code contains an if statementwhose purpose is to verify that the value of x is within alegal range. We show how an attacker can bypass this ifstatement, thereby reading potentially secret data from theprocess’s address space.First, during an initial mistraining phase, the attacker invokes the above code with valid inputs, thereby trainingthe branch predictor to expect that the if will be true.Next, during the exploit phase, the attacker invokes thecode with a value of x outside the bounds of array1.Rather than waiting for determination of the branch result, the CPU guesses that the bounds check will be trueand already speculatively executes instructions that evaluatearray2[array1[x]*4096] using the malicious x. Notethat the read from array2 loads data into the cache at anaddress that is dependent on array1[x] using the maliciousx, scaled so that accesses go to different cache lines and toavoid hardware prefetching effects.When the result of the bounds check is eventually determined, the CPU discovers its error and reverts anychanges made to its nominal microarchitectural state. However, changes made to the cache state are not reverted, so theattacker can analyze the cache contents and find the value ofthe potentially secret byte retrieved in the out-of-bounds readfrom the victim’s memory.Variant 2: Exploiting Indirect Branches. Drawing fromreturn-oriented programming (ROP) [63], in this variant theattacker chooses a gadget from the victim’s address spaceand influences the victim to speculatively execute the gadget.Unlike ROP, the attacker does not rely on a vulnerability inthe victim code. Instead, the attacker trains the Branch TargetBuffer (BTB) to mispredict a branch from an indirect branchinstruction to the address of the gadget, resulting in speculativeexecution of the gadget. As before, while the effects ofincorrect speculative execution on the CPU’s nominal state areeventually reverted, their effects on the cache are not, therebyallowing the gadget to leak sensitive information via a cacheside channel. We empirically demonstrate this, and show howcareful gadget selection allows this method to read arbitrarymemory from the victim.To mistrain the BTB, the attacker finds the virtual addressof the gadget in the victim’s address space, then performsindirect branches to this address. This training is done fromthe attacker’s address space. It does not matter what resides atthe gadget address in the attacker’s address space; all that is

required is that the attacker’s virtual addresses during trainingmatch (or alias to) those of the victim. In fact, as long as theattacker handles exceptions, the attack can work even if thereis no code mapped at the virtual address of the gadget in theattacker’s address space.Other Variants. Further attacks can be designed by varying both the method of achieving speculative execution andthe method used to leak the information. Examples includemistraining return instructions, leaking information via timingvariations, and contention on arithmetic units.C. Targeted Hardware and Current StatusHardware. We have empirically verified the vulnerability of several Intel processors to Spectre attacks, includingIvy Bridge, Haswell, Broadwell, Skylake, and Kaby Lakeprocessors. We have also verified the attack’s applicabilityto AMD Ryzen CPUs. Finally, we have also successfullymounted Spectre attacks on several ARM-based Samsung andQualcomm processors found in popular mobile phones.Current Status. Using the practice of responsible disclosure,disjoint groups of authors of this paper provided preliminaryversions of our results to partially overlapping groups of CPUvendors and other affected companies. In coordination withindustry, the authors also participated in an embargo of theresults. The Spectre family of attacks is documented underCVE-2017-5753 and CVE-2017-5715.D. MeltdownMeltdown [47] is a related microarchitectural attack whichexploits out-of-order execution to leak kernel memory. Meltdown is distinct from Spectre attacks in two main ways. First,unlike Spectre, Meltdown does not use branch prediction.Instead, it relies on the observation that when an instructioncauses a trap, following instructions are executed out-oforder before being terminated. Second, Meltdown exploits avulnerability specific to many Intel and some ARM processorswhich allows certain speculatively executed instructions tobypass memory protection. Combining these issues, Meltdownaccesses kernel memory from user space. This access causes atrap, but before the trap is issued, the instructions that followthe access leak the contents of the accessed memory througha cache covert channel.In contrast, Spectre attacks work on a wider range of processors, including most AMD and ARM processors. Furthermore,the