Fuzzing Binaries for Memory Safety Errors with QASan

Fioraldi, Andrea; D’Elia, Daniele Cono; Querzoni, Leonardo

doi:10.1109/secdev45635.2020.00019

Cited by 20 publications

(14 citation statements)

References 32 publications

(40 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Google announced FuzzBench in March 2020 as "a fully automated, open source, free service for evaluating fuzzers". 8 It tests fuzzers in a controlled environment, comparing their performance across a large number of targets taken from Google OSS-Fuzz, a collection of fuzz targets for opensource software. 9 For each target, the service compares the edge coverage obtained by the fuzzers.…”

Section: A Fuzzbenchmentioning

confidence: 99%

“…Address sanitizer [23] is a very popular sanitizer that checks for certain memory errors. Since it requires source code to produce instrumented target programs, Fioraldi et al have recently proposed QASan [8], a QEMU-based system that implements similar checks for binaries. There is a plethora of other sanitizers, often requiring source code [26].…”

Section: B Run-time Bug Detectionmentioning

confidence: 99%

“…There is a call instruction in TCG, but it serves a different purpose 8. https://security.googleblog.com/2020/03/fuzzbench-fuzzer-benchmarkingas-service.html…”

mentioning

confidence: 99%

See 2 more Smart Citations

SymQEMU: Compilation-based symbolic execution for binaries

Poeplau

Francillon

2021

Proceedings 2021 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Symbolic execution is a powerful technique for software analysis and bug detection. Compilation-based symbolic execution is a recently proposed flavor that has been shown to improve the performance of symbolic execution significantly when source code is available. We demonstrate a novel technique to enable compilation-based symbolic execution of binaries (i.e., without the need for source code). Our system, SymQEMU, builds on top of QEMU, modifying the intermediate representation of the target program before translating it to the host architecture. This enables SymQEMU to compile symbolic-execution capabilities into binaries and reap the associated performance benefits while maintaining architecture independence. We present our approach and implementation, and we show that it outperforms the state-of-the-art binary symbolic executors S2E and QSYM with statistical significance; on some benchmarks, it even achieves better performance than the source-based SymCC. Moreover, our tool has found a previously unknown vulnerability in the well-tested libarchive library, demonstrating its utility in testing real-world software.

show abstract

Section: A Fuzzbenchmentioning

confidence: 99%

Section: B Run-time Bug Detectionmentioning

confidence: 99%

See 1 more Smart Citation

SymQEMU: Compilation-based symbolic execution for binaries

Poeplau

Francillon

2021

Proceedings 2021 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…To date, dozens of techniques have been proposed to detect UAF in testing environments and to prevent UAF exploits in production environments. In terms of detection, most existing solutions rely exclusively on dynamic analysis by instrumenting programs at the IR-level [6], [7], [8], [9], [10], [11], [12] or binary level [13], [14], [15], [16], [17], [18], [19]. While maintaining zero or low false alarms, dynamic analysis approaches have low code coverage and high performance overhead.…”

Section: Introductionmentioning

confidence: 99%

Automated Use-After-Free Detection and Exploit Mitigation: How Far Have We Gone?

Gui

Song

Xiong

et al. 2022

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

C/C++ programs frequently encounter memory errors, such as Use-After-Free (UAF), buffer overflow, and integer overflow. Among these memory errors, UAF vulnerabilities are increasingly being exploited by attackers to disrupt critical software systems, leading to serious consequences, such as remote code execution and data breaches. Researchers have proposed dozens of approaches to detect UAFs in testing environments and to mitigate UAF exploit in production environments. However, to the best of our knowledge, no comprehensive studies have evaluated and compared these approaches. In this paper, we shed light on the current UAF detection and exploit mitigation approaches and provide a systematic overview, comprehensive comparison, and evaluation. Specifically, we evaluate the effectiveness and efficiency of publicly available UAF detection and exploit mitigation tools. The experimental results show that static UAF detectors are suitable for detecting intra-procedural UAFs but are not sufficient to detect inter-procedural UAFs in real-world programs. Dynamic UAF detectors are still the first choice for detecting inter-procedural UAFs. Our evaluation also demonstrates that the runtime overhead of existing UAF exploit mitigation tools is relatively stable whereas the memory overhead may vary dramatically with respect to different programs. Finally, we envision potential valuable future research directions.

show abstract

“…State-of-the-art binary instrumentation for fuzzing splits multi-byte comparisons at emulation time to be able to report successful hits of single bytes (cmpcov or LAF-intel [15]). It may even supply the fuzzer with feedback about compare results (cmplog [5], [9]) or inject address sanitization in an efficient way [7], [10]. Still, they are far from perfect and still get stuck on trivial checksums, complex floating-point calculations, and more complex formats like XML.…”

Section: Introductionmentioning

confidence: 99%

JMPscare: Introspection for Binary-Only Fuzzing

Maier¹,

Seidel²

2021

Proceedings 2021 Workshop on Binary Analysis Research

View full text Add to dashboard Cite

or may even actively guide the fuzzer with waypoints [4].Especially for binary-only fuzzing, after the initial setup runs, getting deeper knowledge about the fuzzer's actual performance, and figure out shortcomings and roadblocks, can be a daunting task. Often, reverse engineers will look at the resulting coverage maps, debug hand-picked, interestinglooking inputs, and load up several collected traces in existing tools like Lighthouse [12] and Dragondance [1]. However, with thousands of queue entries for a fuzzer like AFL ++ , the tools reach their limits. Even if loading all traces as once succeeds, it is hard to spot interesting unreached jumps. A fuzzing queue, or corpus, is commonly used in feedback-based fuzzers and collects interesting test cases that led to new coverage or otherwise new feedback during execution. We deem insights into this queue important to improve the overall harness and fuzzer performance. It shows us which parts of the harness the fuzzer explored and at which branches it got stuck. On complex targets, like a full-blown RTOS, a complete view of basic-blocks (not) reached would not provide the researcher with the same insights. No harness covers all basic blocks in the target: reaching some of the branches may rely on the target to be in a different state. Non-covered basic blocks may be reached with better harnessing and mutations or be completely unreachable. The human-in-the-loop has no chance to see this difference immediately just by looking at a coverage map.To improve this situation, we developed JMPscare, an analysis toolkit that takes all traces in a fuzzer queue into account. The goal is to provide reverse engineers with full insight into their fuzzing campaigns. JMPscare efficiently uncovers nevertaken branches, so-called frontiers. To guide the human-inthe-loop towards interesting frontiers, it performs a Potential New Coverage (PNC) analysis, surfacing frontiers that can lead to large new control flows if traversed., leading to additional corner cases. JMPscare offers a quick solution to overcome simple frontiers through a single click binary patching to force execution in this direction. With this, the fuzzer traverses any roadblocks but triggers false positives if the prior condition is directly responsible for a crash. While JMPscare will work with any target, as long as a program counter trace of the executions can be acquired, JMPscare features a stand-alone trace collection with native unicornafl [11], BaseSAFE [17], and qiling [22] support. For the course of this paper, we evaluate JMPscare using the publicly available MediaTek harness and test case corpus of BaseSAFE. We are able to gather further knowledge about the harness that the original work could not collect and use, for the lack of JMPscare.

show abstract

Fuzzing Binaries for Memory Safety Errors with QASan

Cited by 20 publications

References 32 publications

SymQEMU: Compilation-based symbolic execution for binaries

SymQEMU: Compilation-based symbolic execution for binaries

Automated Use-After-Free Detection and Exploit Mitigation: How Far Have We Gone?

JMPscare: Introspection for Binary-Only Fuzzing

Contact Info

Product

Resources

About