Unleashing Mayhem on Binary Code

Q: What have the authors stated for future works in "Unleashing mayhem on binary code" ?

Future Work: An interesting future direction is to extend MAYHEM to handle more advanced exploitation techniques such as exploiting heapbased buffer overflows, use-after-free vulnerabilities, and information disclosure attacks.

Question

1. What have the authors contributed in "Unleashing mayhem on binary code" ?

2. What have the authors stated for future works in "Unleashing mayhem on binary code" ?

3. What are some of the popular binary-only execution frameworks?

4. What was the downside of using the solver in incremental mode?

Accepted Answer

In this paper the authors present MAYHEM, a new system for automatically finding exploitable bugs in binary ( i. e., executable ) programs.. The working exploits ensure soundness and that each bug report is securitycritical and actionable.. To this end, the authors propose two novel techniques: 1 ) hybrid symbolic execution for combining online and offline ( concolic ) execution to maximize the benefits of both techniques, and 2 ) index-based memory modeling, a technique that allows MAYHEM to efficiently reason about symbolic memory at the binary level.. The authors used MAYHEM to find and demonstrate 29 exploitable vulnerabilities in both Linux and Windows programs, 2 of which were previously undocumented.

Accepted Answer

Future Work:. An interesting future direction is to extend MAYHEM to handle more advanced exploitation techniques such as exploiting heapbased buffer overflows, use-after-free vulnerabilities, and information disclosure attacks.

Accepted Answer

There are several binary-only symbolic execution frameworks such as Bouncer [10], BitFuzz [8], BitTurner [6] FuzzBall [20], McVeto [27], SAGE [13], and S2E [28], which have been used in a variety of application domains.

Accepted Answer

A downside of using the solver in incremental mode was that it made their symbolic execution state mutable—and thus was less memory efficient during their long-running tests.

Accepted Answer

MAYHEM uses three heuristic ranking rules: a) executors exploring new code (e.g., instead of executing known code more times) have high priority, b) executors that identify symbolic memory accesses have higher priority, and c) execution paths where symbolic instruction pointers are detected have the highest priority.

Accepted Answer

When the maximum number of running executors is 1, it meansMAYHEM will produce a disk checkpoint—the average checkpoint size was 30KB—for every symbolic branch,thus is equivalent to offline execution.

Accepted Answer

The fastest program to exploit was the Linux wireless configuration utility iwconfig in 1.90 seconds and the longest was the Windows program Dizzy, which took about 4 hours.

Accepted Answer

Path Selection: MAYHEM applies path prioritization heuristics—as found in systems such as SAGE [13] and KLEE [9]—to decide which path should be explored next.

Accepted Answer

To allow for remote communication between the two components the authors implemented their own cross-platform, light-weight RPC protocol (both in C++ and OCaml).

Accepted Answer

Modeling a symbolic load using a memory object is beneficial when the size of the memory object is significantly smaller than the entire memory (|M| |μ|).

Accepted Answer

It does so by forking off an interpreter for each branch and asserting in the generated formula that the branch guard must be satisfied.

Accepted Answer

The command-line tells MAYHEM to symbolically execute orzHttpd, and open sockets on port 80 to receive symbolic 400-byte long packets.

Accepted Answer

If the authors can’t generate a jump-to-register exploit, the authors try to generate a simpler exploit by making the instruction pointer point directly to a place in memory where the authors can place shellcode.

Accepted Answer

The down-side is that whole-system analysis can be much more expensive, because of the higher state restoration cost and the time spent analyzing kernel code.

Accepted Answer

Row 3 shows that VSA reduces the average number of queries to the SMT solver from ∼54 to ∼14queries per symbolic memory access, and reduces the total time by 75%.

Unleashing Mayhem on Binary Code

Chat with Paper

AI Agents for this Paper

Most frequently asked questions

1. What have the authors contributed in "Unleashing mayhem on binary code" ?

2. What have the authors stated for future works in "Unleashing mayhem on binary code" ?

3. What are some of the popular binary-only execution frameworks?

4. What was the downside of using the solver in incremental mode?

5. What are the three heuristic ranking rules for MAYHEM?

6. What is the fastest execution for a symbolic branch?

7. How long did it take to exploit?

8. What is the heuristics used to decide which path should be explored next?

9. How did the authors implement the OCaml protocol?

10. What is the way to model a symbolic load using a memory object?

11. How does the symbolic execution engine evaluate expressions for each branch?

12. How does the command-line tell MAYHEM to execute orzHttpd?

13. How do the authors generate a jump-to-register exploit?

14. What is the down-side of whole-system analysis?

15. How does VSA reduce the average number of queries to the SMT solver?

Figures

Citations

SOK: (State of) The Art of War: Offensive Techniques in Binary Analysis

Driller: Augmenting Fuzzing Through Selective Symbolic Execution.

VUzzer: Application-aware Evolutionary Fuzzing.

S2E: a platform for in-vivo multi-path analysis of software systems

Angora: Efficient Fuzzing by Principled Search

References

Z3: an efficient SMT solver

Pin: building customized program analysis tools with dynamic instrumentation

KLEE: unassisted and automatic generation of high-coverage tests for complex systems programs

Symbolic execution and program testing

CUTE: a concolic unit testing engine for C

Related Papers (5)

KLEE: unassisted and automatic generation of high-coverage tests for complex systems programs

Driller: Augmenting Fuzzing Through Selective Symbolic Execution.

SOK: (State of) The Art of War: Offensive Techniques in Binary Analysis

Automated Whitebox Fuzz Testing.

CUTE: a concolic unit testing engine for C