Arrays Made Simpler: An Efficient, Scalable and Thorough Preprocessing

Farinier, Benjamin; David, Robin; Bardin, Sébastien; Lemerre, Matthieu

doi:10.29007/dc9b

Cited by 11 publications

(22 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…If we can determine that the index a of the load is distinct from the index of the second store a 2 then, by the theory of arrays, we have t 2 = t 1 thus the path x → t 2 and all of its subpaths are redundant. We rely on a well-known optimization for symbolic arrays called read-over-write [37] to detect and prune these redundant cases.…”

Section: Haunted Relsementioning

confidence: 99%

“…2) Evaluation of load expressions: Load expressions can either take their value from a pending store in the store buffer with a matching address via store-to-load forwarding; or can speculatively bypass pending stores in the store buffer and take their value from the main memory [30]. Instead of considering all possible interleavings between a load expression and prior stores in the store-buffer, we use read-over-write [37] to identify and discard most cases in which the load and a prior store naturally commute. Read-over-write is a well known simplification for the theory of arrays which resolves select operations on symbolic arrays ahead of the solver.…”

Section: Haunted Relsementioning

confidence: 99%

“…BINSEC/HAUNTED explores the program in a depthfirst search manner, prioritizing transient paths over regular paths, and reports SCT violations with counterexamples (i.e., initial configurations and speculation choices leading to the violation). It uses the SMT solver Boolector [40], currently the best for the theory of bitvectors [37], [41].…”

Section: Binsec/haunted a Tool For Haunted Relsementioning

confidence: 99%

See 2 more Smart Citations

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

Daniel¹,

Bardin²,

Rezk³

2021

Proceedings 2021 Network and Distributed System Security Symposium

Self Cite

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: Haunted Relsementioning

confidence: 99%

Section: Haunted Relsementioning

confidence: 99%

Section: Binsec/haunted a Tool For Haunted Relsementioning

confidence: 99%

See 1 more Smart Citation

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

Daniel¹,

Bardin²,

Rezk³

2021

Proceedings 2021 Network and Distributed System Security Symposium

Self Cite

View full text Add to dashboard Cite

show abstract

“…We will use the type Bv m , where m is a constant number, to represent symbolic bitvector expressions. The memory is modeled with a logical array [65], [66] of type (Array Bv 32 Bv 8 ) (assuming a 32 bit architecture). A logical array is a function (Array I V) that maps each index i ∈ I to a value v ∈ V. Operations over arrays are:…”

Section: Binary-level Symbolic Executionmentioning

confidence: 99%

Binsec/Rel: Efficient Relational Symbolic Execution for Constant-Time at Binary-Level

Daniel

Bardin

Rezk

2020

2020 IEEE Symposium on Security and Privacy (SP)

View full text Add to dashboard Cite

The constant-time programming discipline (CT) is an efficient countermeasure against timing side-channel attacks, requiring the control flow and the memory accesses to be independent from the secrets. Yet, writing CT code is challenging as it demands to reason about pairs of execution traces (2hypersafety property) and it is generally not preserved by the compiler, requiring binary-level analysis. Unfortunately, current verification tools for CT either reason at higher level (C or LLVM), or sacrifice bug-finding or bounded-verification, or do not scale. We tackle the problem of designing an efficient binary-level verification tool for CT providing both bug-finding and bounded-verification. The technique builds on relational symbolic execution enhanced with new optimizations dedicated to information flow and binary-level analysis, yielding a dramatic improvement over prior work based on symbolic execution. We implement a prototype, BINSEC/REL, and perform extensive experiments on a set of 338 cryptographic implementations, demonstrating the benefits of our approach in both bug-finding and bounded-verification. Using BINSEC/REL, we also automate a previous manual study of CT preservation by compilers. Interestingly, we discovered that gcc -O0 and backend passes of clang introduce violations of CT in implementations that were previously deemed secure by a state-of-the-art CT verification tool operating at LLVM level, showing the importance of reasoning at binary-level.1 Some versions of CT also require that the size of operands of variable-time instructions (e.g. integer division) is independent from secrets.

show abstract

“…Binsec/RSE emits quantified formulas in the theory of bitvectors and arrays (arrays are used to model memory) which are then solved by the quantified solver Z3 [22]. We reuse the recent ROW simplification [26] to reduces the number of array indexations. The source code of Binsec/RSE, the test suite and the case studies of this section are available for reproduction at https://github.com/binsec/cav2021-artifacts and https:// zenodo.org/record/4721753.…”

Section: Methodsmentioning

confidence: 99%

Not All Bugs Are Created Equal, But Robust Reachability Can Tell the Difference

Girol

Farinier

Bardin

2021

Computer Aided Verification

Self Cite

View full text Add to dashboard Cite

This paper introduces a new property called robust reachability which refines the standard notion of reachability in order to take replicability into account. A bug is robustly reachable if a controlled input can make it so the bug is reached whatever the value of uncontrolled input. Robust reachability is better suited than standard reachability in many realistic situations related to security (e.g., criticality assessment or bug prioritization) or software engineering (e.g., replicable test suites and flakiness). We propose a formal treatment of the concept, and we revisit existing symbolic bug finding methods through this new lens. Remarkably, robust reachability allows differentiating bounded model checking from symbolic execution while they have the same deductive power in the standard case. Finally, we propose the first symbolic verifier dedicated to robust reachability: we use it for criticality assessment of 4 existing vulnerabilities, and compare it with standard symbolic execution.

show abstract

Arrays Made Simpler: An Efficient, Scalable and Thorough Preprocessing

Cited by 11 publications

References 20 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

Binsec/Rel: Efficient Relational Symbolic Execution for Constant-Time at Binary-Level

Not All Bugs Are Created Equal, But Robust Reachability Can Tell the Difference

Contact Info

Product

Resources

About