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

Abstract

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

Reflections on the Experimental Evaluation of a Binary-Level Symbolic Analyzer for Spectre

“…This section details the experimental protocol set up in [6]. We outline clear research questions and protocol (Section IV-A), we detail the benchmarks used for our evaluation (Section IV-B) and we conclude with general takeaways on our methodology stemming from the software engineering community (Section IV-C).…”

“…This section presents the experimental results reported in [6] for Spectre-PHT (Section V-A) and Spectre-STL (Section V-B). Performance of BINSEC/HAUNTED are reported on a set of real word cryptographic binaries to answer RQ1; and compared to the baseline Explicit RelSE to answer RQ2.…”

“…validation); • Section VIII presents our intermediate and unsuccessful results, illustrating difficulties and questions that arise when implementing a symbolic analyzer; • Section IX reports our failures when running or reproducing our experiments, together with solutions we devised to avoid repeating them. The content presented in this paper is original, except for the context (Sections I and II), experimental protocol (Sections IV-A and IV-B) and experimental results (Sections V-A, V-B and VI-B), which are taken from our previous work [6] for the reader's convenience. Novel content includes a description of our testbed (Section III), discussions about our experimental setup and evaluation (Sections IV-C, V-C, VI-A and VI-C), and presentation of intermediate results and failures (Sections VIII and IX).…”

“…BINSEC/HAUNTED. BINSEC/HAUNTED [6] is a binary-level analysis tool for Spectre-PHT and Spectre-STL. It relies on relational symbolic execution and performs bug-finding and bounded-verification for speculative constant-time (SCT) at binary-level.…”

“…• Section II introduces technical details that are necessary for the comprehension of this paper. We refer the interested reader to [6] for more details on our contributions; • Section III presents our testbed setup, along with general discussions on availability of artifacts and reproducibility of results; • Section IV details our experimental protocol, along with general discussions on our methodology stemming from the software engineering community;…”