mayhem-oakland-12

More documents

Recommendations

Info

(unlike standard concolic execution), and the re-executionhappens concretely. Figure 3 shows the intuition behindhybrid execution. We provide a detailed comparison betweenonline, offline, and hybrid execution in §VIII-C.C. Design and Implementation of the CECThe CEC takes in the binary program, a list of inputsources to be considered symbolic, and an optional checkpointinput that contains execution state information froma previous run. The CEC concretely executes the program,hooks input sources and performs taint analysis on inputvariables. Every basic block that contains tainted instructionsis sent to the SES for symbolic execution. As a response,the CEC receives the address of the next basic block tobe executed and whether to save the current state as arestoration point. Whenever an execution path is complete,the CEC context-switches to an unexplored path selectedby the SES and continues execution. The CEC terminatesonly if all possible execution paths have been explored or athreshold is reached. If we provide a checkpoint, the CECfirst executes the program concretely until the checkpointand then continues execution as before.Virtualization Layer. During an online execution run, theCEC handles multiple concrete execution states of theanalyzed program simultaneously. Each concrete executionstate includes the current register context, memory andOS state (the OS state contains a snapshot of the virtualfilesystem, network and kernel state). Under the guidanceof the SES and the path selector, the CEC context switchesbetween different concrete execution states depending on thesymbolic executor that is currently active. The virtualizationlayer mediates all system calls to the host OS and emulatesthem. Keeping separate copies of the OS state ensures thereare no side-effects across different executions. For instance,if one executor writes a value to a file, this modificationwill only be visible to the current execution state—all otherexecutors will have a separate instance of the same file.Efficient State Snapshot. Taking a full snapshot of theconcrete execution state at every fork is very expensive. Tomitigate the problem, CEC shares state across executionstates–similar to other systems [9], [28]. Whenever executionforks, the new execution state reuses the state of the parentexecution. Subsequent modifications to the state are recordedin the current execution.D. Design and Implementation of the SESThe SES manages the symbolic execution environmentand decides which paths are executed by the CEC. Theenvironment consists of a symbolic executor for each path,a path selector which determines which feasible path to runnext, and a checkpoint manager.The SES caps the number of symbolic executors to keep inmemory. When the cap is reached, MAYHEM stops generatingnew interpreters and produces checkpoints; execution statesthat will explore program paths that MAYHEM was unableto explore in the first run due to the memory cap. Eachcheckpoint is prioritized and used by MAYHEM to continueexploration of these paths at a subsequent run. Thus, when allpending execution paths terminate, MAYHEM selects a newcheckpoint and continues execution—until all checkpointsare consumed and MAYHEM exits.Each symbolic executor maintains two contexts (as state):a variable context containing all symbolic register valuesand temporaries, and a memory context keeping track of allsymbolic data in memory. Whenever execution forks, theSES clones the current symbolic state (to keep memory low,we keep the execution state immutable to take advantage ofcopy-on-write optimizations—similar to previous work [9],[28]) and adds a new symbolic executor to a priority queue.This priority queue is regularly updated by our path selectorto include the latest changes (e.g., which paths were explored,instructions covered, and so on).Preconditioned Symbolic Execution: MAYHEM implementspreconditioned symbolic execution as in AEG [2].In preconditioned symbolic execution, a user can optionallygive a partial specification of the input, such as a prefixor length of the input, to reduce the range of search space.If a user does not provide a precondition, then SES triesto explore all feasible paths. This corresponds to the userproviding the minimum amount of information to the system.Path Selection: MAYHEM applies path prioritizationheuristics—as found in systems such as SAGE [13] andKLEE [9]—to decide which path should be explored next.Currently, MAYHEM uses three heuristic ranking rules: a)executors exploring new code (e.g., instead of executingknown code more times) have high priority, b) executorsthat identify symbolic memory accesses have higher priority,and c) execution paths where symbolic instruction pointersare detected have the highest priority. The heuristics aredesigned to prioritize paths that are most likely to contain abug. For instance, the first heuristic relies on the assumptionthat previously explored code is less likely to contain a bugthan new code.E. Performance TuningMAYHEM employs several optimizations to speed-upsymbolic execution. We present three optimizations thatwere most effective: 1) independent formula, 2) algebraicsimplifications, and 3) taint analysis.Similar to KLEE [9], MAYHEM splits the path predicateto independent formulas to optimize solver queries. Asmall implementation difference compared to KLEE is thatMAYHEM keeps a map from input variables to formulas at alltimes. It is not constructed only for querying the solver (thisrepresentation allows more optimizations §V). MAYHEM alsoapplies other standard optimizations as proposed by previoussystems such as the constraint subsumption optimization [13],a counter-example cache [9] and others. MAYHEM also
simplifies symbolic expressions and formulas by applyingalgebraic simplifications, e.g. x ⊕ x = 0, x & 0 = 0,and so on.Recall from §IV-C, MAYHEM uses taint analysis [11],[23] to selectively execute instruction blocks that deal withsymbolic data. This optimization gives a 8× speedup onaverage over executing all instruction blocks (see §VIII-G).V. INDEX-BASED MEMORY MODELINGMAYHEM introduces an index-based memory model as apractical approach to handling symbolic memory loads. Theindex-based model allows MAYHEM to adapt its treatmentof symbolic memory based on the value of the index. In thissection we present the entire memory model of MAYHEM.MAYHEM models memory as a map µ : I → E from 32-bit indices (i) to expressions (e). In a load(µ,i) expression,we say that index i indexes memory µ, and the loaded valuee represents the contents of the i th memory cell. A load witha concrete index i is directly translated by MAYHEM intoan appropriate lookup in µ (i.e., µ[i]). A store(µ, i, e)instruction results in a new memory µ[i ← e] where i ismapped to e.A. Previous Work & Symbolic Index ModelingA symbolic index occurs when the index used in a memorylookup is not a number, but an expression—a pattern thatappears very frequently in binary code. For example, a Cswitch(c) statement is compiled down to a jump-tablelookup where the input character c is used as the index.Standard string conversion functions (such as ASCII toUnicode and vice versa, to_lower, to_upper, etc.) areall in this category.Handling arbitrary symbolic indices is notoriously hard,since a symbolic index may (in the worst case) reference anycell in memory. Previous research and state-of-the-art toolsindicate that there are two main approaches for handling asymbolic index: a) concretizing the index and b) allowingmemory to be fully symbolic.First, concretizing means instead of reasoning aboutall possible values that could be indexed in memory, weconcretize the index to a single specific address. Thisconcretization can reduce the complexity of the producedformulas and improve solving/exploration times. However,constraining the index to a single value may cause us tomiss paths—for instance, if they depend on the value ofthe index. Concretization is the natural choice for offlineexecutors, such as SAGE [13] or BitBlaze [5], since only asingle memory address is accessed during concrete execution.Reasoning about all possible indices is also possible bytreating memory as fully symbolic. For example, tools suchas McVeto [27], BAP [15] and BitBlaze [5] offer capabilitiesto handle symbolic memory. The main tradeoff—whencompared with the concretization approach—is performance.Formulas involving symbolic memory are more expressive,thus solving/exploration times are usually higher.B. Memory Modeling in MAYHEMThe first implementation of MAYHEM followed the simpleconcretization approach and concretized all memory indices.This decision proved to be severely limiting in that selectinga single address for the index usually did not allow us tosatisfy the exploit payload constraints. Our experiments showthat 40% of the examples require us to handle symbolicmemory—simple concretization was insufficient (see §VIII).The alternative approach was symbolic memory. To avoidthe scalability problems associated with fully symbolicmemory, MAYHEM models memory partially, where writesare always concretized, but symbolic reads are allowed to bemodeled symbolically. In the rest of this section we describethe index-based memory model of MAYHEM in detail, aswell as some of the key optimizations.Memory Objects. To model symbolic reads, MAYHEMintroduces memory objects. Similar to the global memory µ,a memory object M is also a map from 32-bit indices toexpressions. Unlike the global memory however, a memoryobject is immutable. Whenever a symbolic index is used toread memory, MAYHEM generates a fresh memory objectM that contains all values that could be accessed by theindex—M is a partial snapshot of the global memory.Using the memory object, MAYHEM can reduce theevaluation of a load(µ, i) expression to M[i]. Note, thatthis is semantically equivalent to returning µ[i]. The keydifference is in the size of the symbolic array we introducein the formula. In most cases, the memory object M willbe orders of magnitude smaller than the entire memory µ.Memory Object Bounds Resolution. Instantiating the memoryobject requires MAYHEM to find all possible values ofa symbolic index i. In the worst case, this may require upto 2 32 queries to the solver (for 32-bit memory addresses).To tackle this problem MAYHEM exchanges some accuracyfor scalability by resolving the bounds [L, U] of the memoryregion—where L is the lower and U is the upper bound of theindex. The bounds need to be conservative, i.e., all possiblevalues of the index should be within the [L, U] interval. Notethat the memory region does not need to be continuous, forexample i might have only two realizable values (L and U).To obtain these bounds MAYHEM uses the solver toperform binary search on the value of the index in the contextof the current path predicate. For example, initially for thelowest bound of a 32-bit i: L ∈ [0, 2 32 − 1]. If i < 232 −12is satisfiable then L ∈ [0, 232 −12− 1] while unsatisfiabilityindicates that L ∈ [ 232 −12, 2 32 − 1]. We repeat the processuntil we recover both bounds. Using the bounds we can nowinstantiate the memory object (using a fresh symbolic arrayM) as follows: ∀i ∈ [L, U] : M[i] = µ[i].The bounds resolution algorithm described above issufficient to generate a conservative representation of memoryobjects and allow MAYHEM to reason about symbolicmemory reads. In the rest of the section we detail the main
Page 3: In orzHttpd, each HTTP connection i
Page 8 and 9: ite( n < 128, L, R )ite( n < 91, it
Page 10 and 11: exploitable policies are violated,
Page 13 and 14: AEGMAYHEMProgram Time LLVM Time ASM
Page 15: XI. CONCLUSIONWe presented MAYHEM,

mayhem-oakland-12

Create successful ePaper yourself

Delete template?

Save as template?