oo7: Low-Overhead Defense Against Spectre Attacks via Program Analysis

Wang, Guanhua; Chattopadhyay, Sudipta; Gotovchits, Ivan; Mitra, Tulika; Roychoudhury, Abhik

doi:10.1109/tse.2019.2953709

Cited by 62 publications

(81 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To date, there are four known main variants of Spectre attacks [2]. Most works on analyzers [3], [4], [9]- [12] only focus on the Pattern History Table (PHT) variant (a.k.a Spectre-v1 [1]) which exploits conditional branches, yet they struggle on mediumsize binary code (cf. Table V).…”

Section: Introductionmentioning

confidence: 99%

Hunting the Haunter — Efficient Relational Symbolic Execution for Spectre with Haunted RelSE

Daniel¹,

Bardin²,

Rezk³

2021

Proceedings 2021 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Spectre are microarchitectural attacks which were made public in January 2018. They allow an attacker to recover secrets by exploiting speculations. Detection of Spectre is particularly important for cryptographic libraries and defenses at the software level have been proposed. Yet, defenses correctness and Spectre detection pose challenges due on one hand to the explosion of the exploration space induced by speculative paths, and on the other hand to the introduction of new Spectre vulnerabilities at different compilation stages. We propose an optimization, coined Haunted RelSE, that allows scalable detection of Spectre vulnerabilities at binary level. We prove the optimization semantically correct w.r.t. the more naive explicit speculative exploration approach used in state-of-the-art tools. We implement Haunted RelSE in a symbolic analysis tool, and extensively test it on a wellknown litmus testset for Spectre-PHT, and on a new litmus testset for Spectre-STL, which we propose. Our technique finds more violations and scales better than state-of-the-art techniques and tools, analyzing real-world cryptographic libraries and finding new violations. Thanks to our tool, we discover that indexmasking-a standard defense for Spectre-PHT-and well-known gcc options to compile position independent executables introduce Spectre-STL violations. We propose and verify a correction to index-masking to avoid the problem. addresses the Store to Load (STL) variant (a.k.a Spectre-v4 [13]), which exploits the memory dependence predictor. Unfortunately, Pitchfork does not scale for analyzing Spectre-STL, even on small programs (cf. Table IV). Other variants are currently out-of-scope of static analyzers (see Sections II and VII). Goal and challenges. In this paper, we propose a novel technique to detect Spectre-PHT and Spectre-STL vulnerabilities and we implement it in a new static analyzer for binary code. Two challenges arise in the design of such an analyzer: C1 First, the details of the microarchitecture cannot be fully included in the analysis because they are not public in general and not easy to obtain. Yet the challenge is to find an abstraction powerful enough to capture side channels attacks due to microarchitectural state. C2 Second, exploration of all possible speculative executions does not scale because it quickly leads to state explosion. The challenge is how to optimize this exploration in order to make the analysis applicable to real code. Proposal. We tackle challenge C1 by targeting a relational security property coined in the literature as speculative constanttime [5], a property reminiscent of constant-time [14], widely used in cryptographic implementations. Speculative constanttime takes speculative executions into account without explicitly modeling intrincate microarchitectural details. However, it is well known that constant-time programming is not necessarily preserved by compilers [15], [16], so our analysis operates at binary level-besides, it is compiler-agnostic and does not require source code. For thi...

show abstract

Section: Introductionmentioning

confidence: 99%

Hunting the Haunter — Efficient Relational Symbolic Execution for Spectre with Haunted RelSE

Daniel¹,

Bardin²,

Rezk³

2021

Proceedings 2021 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…In contrast, our type system enforces speculative constant-time when program instructions are executed out-of-order with unbounded speculationÐ and our tool Blade automatically synthesizes repairs. Separately, oo7 [Wang et al 2018] statically analyzes a binary from a set of untrusted input sources, detecting vulnerable patterns and inserting fences in turn. Our tool, Blade, not only repairs vulnerable programs without user annotation, but ensures that program patches contain a minimum number of fences.…”

Section: Related Workmentioning

confidence: 99%

Automatically eliminating speculative leaks from cryptographic code with blade

Vassena

Disselkoen

Gleissenthall

et al. 2021

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

We introduce Blade, a new approach to automatically and efficiently eliminate speculative leaks from cryptographic code. Blade is built on the insight that to stop leaks via speculative execution, it suffices to cut the dataflow from expressions that speculatively introduce secrets ( sources ) to those that leak them through the cache ( sinks ), rather than prohibit speculation altogether. We formalize this insight in a static type system that (1) types each expression as either transient , i.e., possibly containing speculative secrets or as being stable , and (2) prohibits speculative leaks by requiring that all sink expressions are stable. Blade relies on a new abstract primitive, protect , to halt speculation at fine granularity. We formalize and implement protect using existing architectural mechanisms, and show how Blade’s type system can automatically synthesize a minimal number of protect s to provably eliminate speculative leaks. We implement Blade in the Cranelift WebAssembly compiler and evaluate our approach by repairing several verified, yet vulnerable WebAssembly implementations of cryptographic primitives. We find that Blade can fix existing programs that leak via speculation automatically , without user intervention, and efficiently even when using fences to implement protect .

show abstract

“…The first objective is to detect the Spectre pattern in binaries. After Spectre unveiling, several attempts have been made to detect this pattern in compilers and to insert fence instructions to secure the binaries [12]. However, as OoO processors automatically speculate over all branches, the pattern can be hidden behind complex control-flow operations.…”

Section: A Detecting Spectre Patternsmentioning

confidence: 99%

“…Finally, OO7 [12] uses a tainting analysis to detect whether a dangerous value (i.e., a value which can be controlled by an attacker) can be used as an address for a speculative load. If such a pattern is detected, a FENCE instruction can be inserted to make the binaries safe.…”

Section: Related Workmentioning

confidence: 99%

GhostBusters: Mitigating Spectre Attacks on a DBT-Based Processor

Rokicki

2020

2020 Design, Automation &Amp; Test in Europe Conference &Amp; Exhibition (DATE)

View full text Add to dashboard Cite

Unveiled early 2018, the Spectre vulnerability affects most of the modern high-performance processors. Spectre variants exploit the speculative execution mechanisms and a cache side-channel attack to leak secret data. As of today, the main countermeasures consist of turning off the speculation, which drastically reduces the processor performance. In this work, we focus on a different kind of micro-architecture: the DBT based processors, such as Transmeta Crusoe [1], NVidia Denver [2], or Hybrid-DBT [3]. Instead of using complex outof-order (OoO) mechanisms, those cores combines a software Dynamic Binary Translation mechanism (DBT) and a parallel in-order architecture, typically a VLIW core. The DBT is in charge of translating and optimizing the binaries before their execution. Studies show that DBT based processors can reach the performance level of OoO cores for regular enough applications. In this paper, we demonstrate that, even if those processors do not use OoO execution, they are still vulnerable to Spectre variants, because of the DBT optimizations. However, we also demonstrate that those systems can easily be patched, as the DBT is done in software and has fine-grained control over the optimization process.

show abstract

oo7: Low-Overhead Defense Against Spectre Attacks via Program Analysis

Cited by 62 publications

References 15 publications

Hunting the Haunter — Efficient Relational Symbolic Execution for Spectre with Haunted RelSE

Hunting the Haunter — Efficient Relational Symbolic Execution for Spectre with Haunted RelSE

Automatically eliminating speculative leaks from cryptographic code with blade

GhostBusters: Mitigating Spectre Attacks on a DBT-Based Processor

Contact Info

Product

Resources

About