Rethinking pointer reasoning in symbolic execution

Abstract

Symbolic execution is a popular program analysis technique that allows seeking for bugs by reasoning over multiple alternative execution states at once. As the number of states to explore may grow exponentially, a symbolic executor may quickly run out of space. For instance, a memory access to a symbolic address may potentially reference the entire address space, leading to a combinatorial explosion of the possible resulting execution states. To cope with this issue, state-of-the-art executors concretize symbolic addresses that span memory intervals larger than some threshold. Unfortunately, this could result in missing interesting execution states, e.g., where a bug arises. In this paper we introduce MEMSIGHT, a new approach to symbolic memory that reduces the need for concretization, hence offering the opportunity for broader state explorations and more precise pointer reasoning. Rather than mapping address instances to data as previous tools do, our technique maps symbolic address expressions to data, maintaining the possible alternative states resulting from the memory referenced by a symbolic address in a compact, implicit form. A preliminary experimental investigation on prominent benchmarks from the DARPA Cyber Grand Challenge shows that MEMSIGHT enables the exploration of states unreachable by previous techniques. Blessed are the forgetful, for they get the better even of their blunders.

A Survey of Symbolic Execution Techniques

“…Consider the C code of Figure 1 and assume that our goal is to determine which inputs make the assert at line 8 of function foobar fail. Since each 4-byte input parameter can take as many as 2 32 distinct integer values, the approach of running concretely function foobar on randomly generated inputs will unlikely pick up exactly the assert-failing inputs. By evaluating the code using symbols for its inputs, instead of concrete values, symbolic execution overcomes this limitation and makes it possible to reason on classes of inputs, rather than single input values.…”

“…• Representing memory in a compact form. This approach was taken in [32], which maps symbolic -rather than concrete -address expressions to data, representing the possible alternative states resulting from referencing memory using symbolic addresses in a compact, implicit form. Queries are offloaded to efficient paged interval tree implementations to determine which stored data are possibly referenced by a memory read operation.…”

Memory models in symbolic execution: key ideas and new thoughts

“…A preliminary version [7] of this work appeared in the Proceedings of the 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE 2017), where we introduced the main idea behind MEMSIGHT (Section 3) and presented a preliminary experimental evaluation related to MEMSIGHT when integrated into ANGR (Section 5.2.2). ‡ For our example to be meaningful, we assume that b resides in memory rather than in a CPU register.…”

“…A crucial design goal for our approach is that it should be general enough not only to support bug detection but also to be valuable in application contexts where users are interested in possible consequences of these bugs, for example, understanding how they can be exploited.Our approach, which we call MEMSIGHT, natively accounts for merging [3,4], a mainstream performance enabler in symbolic executors. We integrated MEMSIGHT into the state-of-the-art symbolic executors ANGR [5] and KLEE [6]: an experimental evaluation shows that MEMSIGHT allows for broader state exploration on prominent benchmarks analysed with ANGR, while it provides valuable run-time speedups when symbolically executing real-world programs under KLEE.A preliminary version [7] of this work appeared in the Proceedings of the 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE 2017), where we introduced the main idea behind MEMSIGHT (Section 3) and presented a preliminary experimental evaluation related to MEMSIGHT when integrated into ANGR (Section 5.2.2). ‡ For our example to be meaningful, we assume that b resides in memory rather than in a CPU register.…”

Reconstructing C2 Servers for Remote Access Trojans with Symbolic Execution

“…The output is a collection of execution traces enriched with symbolic constraints on the data buffers exchanged throughout communications. Unfortunately, such traces typically encompass at most one command due to scalability issues, and may come in numbers often much greater than the supported commands due to the nature of the symbolic exploration: for instance, multiple paths can be generated for the same command when its handler contains loops or when memory is dereferenced using a symbolic pointer [3,11]. Another problem is that such reports cannot be merged to form longer paths descriptive of communication patterns with the C2 server, as protocol rules may shape subsequent packets differently than in a naive concatenation of recorded communications (consider for instance the use of sequence numbers).…”