PTfuzz: Guided Fuzzing With Processor Trace Feedback

Zhang, Gen; Zhou, Xu; Luo, Yingqi; Wu, Xugang; Min, Erxue

doi:10.1109/access.2018.2851237

Cited by 57 publications

(41 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For white-box (source-available) binaries, code coverage is measured through instrumentation inserted at compile-time [4], [5], [6]. For black-box (sourceunavailable) binaries, it is generally measured through instrumentation inserted dynamically [5], [7] or statically through binary rewriting [10], or through instrumentation-free hardwareassisted tracing [11], [12], [4].…”

Section: Matthew Hicks Virginia Tech Mdhicks2@vtedumentioning

confidence: 99%

“…6) Return to step 2 and repeat. Coverage-guided fuzzers trace code coverage during execution via binary instrumentation [5], [6], [4], system emulation [5], [11], [24], or hardware-assisted mechanisms [11], [4], [12]. All coverage-guided fuzzers are based on one of three metrics of code coverage: basic blocks, basic block edges, or basic block paths.…”

Section: B Coverage-guided Fuzzingmentioning

confidence: 99%

See 1 more Smart Citation

Full-Speed Fuzzing: Reducing Fuzzing Overhead through Coverage-Guided Tracing

Nagy

Hicks

2019

2019 IEEE Symposium on Security and Privacy (SP)

View full text Add to dashboard Cite

Coverage-guided fuzzing is one of the most successful approaches for discovering software bugs and security vulnerabilities. Of its three main components: (1) test case generation, (2) code coverage tracing, and (3) crash triage, code coverage tracing is a dominant source of overhead. Coverageguided fuzzers trace every test case's code coverage through either static or dynamic binary instrumentation, or more recently, using hardware support. Unfortunately, tracing all test cases incurs significant performance penalties-even when the overwhelming majority of test cases and their coverage information are discarded because they do not increase code coverage.To eliminate needless tracing by coverage-guided fuzzers, we introduce the notion of coverage-guided tracing. Coverageguided tracing leverages two observations: (1) only a fraction of generated test cases increase coverage, and thus require tracing; and (2) coverage-increasing test cases become less frequent over time. Coverage-guided tracing encodes the current frontier of coverage in the target binary so that it self-reports when a test case produces new coverage-without tracing. This acts as a filter for tracing; restricting the expense of tracing to only coverage-increasing test cases. Thus, coverage-guided tracing trades increased time handling coverage-increasing test cases for decreased time handling non-coverage-increasing test cases.To show the potential of coverage-guided tracing, we create an implementation based on the static binary instrumentor Dyninst called UnTracer. We evaluate UnTracer using eight real-world binaries commonly used by the fuzzing community. Experiments show that after only an hour of fuzzing, UnTracer's average overhead is below 1%, and after 24-hours of fuzzing, UnTracer approaches 0% overhead, while tracing every test case with popular white-and black-box-binary tracers AFL-Clang, AFL-QEMU, and AFL-Dyninst incurs overheads of 36%, 612%, and 518%, respectively. We further integrate UnTracer with the stateof-the-art hybrid fuzzer QSYM and show that in 24-hours of fuzzing, QSYM-UnTracer executes 79% and 616% more test cases than QSYM-Clang and QSYM-QEMU, respectively.

show abstract

Section: Matthew Hicks Virginia Tech Mdhicks2@vtedumentioning

confidence: 99%

Section: B Coverage-guided Fuzzingmentioning

confidence: 99%

Full-Speed Fuzzing: Reducing Fuzzing Overhead through Coverage-Guided Tracing

Nagy

Hicks

2019

2019 IEEE Symposium on Security and Privacy (SP)

View full text Add to dashboard Cite

show abstract

“…Our evaluation on PTFuzzer shows much worse performance than the results reported in[38]. We believe this is mainly because our benchmarks have higher complexities and the seeds we use trigger deeper execution.…”

mentioning

confidence: 60%

“…7.1.2 Hardware-assisted Fuzzing. Motivated by the inefficiency of dynamic instrumentation based fuzzing systems, hardware-assisted fuzzing techniques were proposed recently [38]. Similar to PTrix, by leveraging the newly available hardware tracing component-Intel PT [1], Honggfuzz [5] and kAFL [29] efficiently collect the execution trace from the target program.…”

Section: Binary Compatible Coverage-based Fuzzingmentioning

confidence: 99%

PTrix

Chen

et al. 2019

Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security

View full text Add to dashboard Cite

Despite its effectiveness in uncovering software defects, American Fuzzy Lop (AFL), one of the best grey-box fuzzers, is inefficient when fuzz-testing source-unavailable programs. AFL's binary-only fuzzing mode, QEMU-AFL, is typically 2-5× slower than its sourceavailable fuzzing mode. The slowdown is largely caused by the heavy dynamic instrumentation.Recent fuzzing techniques use Intel Processor Tracing (PT), a light-weight tracing feature supported by recent Intel CPUs, to remove the need of dynamic instrumentation. However, we found that these PT-based fuzzing techniques are even slower than QEMU-AFL when fuzzing real-world programs, making them less effective than QEMU-AFL. This poor performance is caused by the slow extraction of code coverage information from highly compressed PT traces.In this work, we present the design and implementation of PTrix, which fully unleashes the benefits of PT for fuzzing via three novel techniques. First, PTrix introduces a scheme to highly parallel the processing of PT trace and target program execution. Second, it directly takes decoded PT trace as feedback for fuzzing, avoiding the expensive reconstruction of code coverage information. Third, PTrix maintains the new feedback with stronger feedback than edge-based code coverage, which helps reach new code space and defects that AFL may not.We evaluated PTrix by comparing its performance with the stateof-the-art fuzzers. Our results show that, given the same amount of time, PTrix achieves a significantly higher fuzzing speed and reaches into code regions missed by the other fuzzers. In addition, PTrix identifies 35 new vulnerabilities in a set of previously wellfuzzed binaries, showing its ability to complement existing fuzzers. CCS CONCEPTS• Security and privacy → Software security engineering.

show abstract

“…Companies such as Google and Apple have deployed fuzzing tools to discover vulnerabilities, and researchers have proposed various fuzzing techniques [4,6,7,12,18,29,33,43,45,47,56,60,61]. Specifically, coverageguided fuzzing [4,6,12,18,33,43,45,56,61] has been actively studied in recent years. In contrast to generational fuzzing, which generates inputs based on given format specifications [2,3,16], coverage-guided fuzzing does not require knowledge such as input format or program specifications.…”

Section: Introductionmentioning

confidence: 99%

Not All Coverage Measurements Are Equal: Fuzzing by Coverage Accounting for Input Prioritization

Wang¹,

Jia²,

Liu³

et al. 2020

Proceedings 2020 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Coverage-based fuzzing has been actively studied and widely adopted for finding vulnerabilities in real-world software applications. With coverage information, such as statement coverage and transition coverage, as the guidance of input mutation, coverage-based fuzzing can generate inputs that cover more code and thus find more vulnerabilities without prerequisite information such as input format. Current coveragebased fuzzing tools treat covered code equally. All inputs that contribute to new statements or transitions are kept for future mutation no matter what the statements or transitions are and how much they impact security. Although this design is reasonable from the perspective of software testing that aims at full code coverage, it is inefficient for vulnerability discovery since that 1) current techniques are still inadequate to reach full coverage within a reasonable amount of time, and that 2) we always want to discover vulnerabilities early so that it can be fixed promptly. Even worse, due to the non-discriminative code coverage treatment, current fuzzing tools suffer from recent anti-fuzzing techniques and become much less effective in finding vulnerabilities from programs enabled with anti-fuzzing schemes. To address the limitation caused by equal coverage, we propose coverage accounting, a novel approach that evaluates coverage by security impacts. Coverage accounting attributes edges by three metrics based on three different levels: function, loop and basic block. Based on the proposed metrics, we design a new scheme to prioritize fuzzing inputs and develop TortoiseFuzz, a greybox fuzzer for finding memory corruption vulnerabilities. We evaluated TortoiseFuzz on 30 real-world applications and compared it with 6 state-of-the-art greybox and hybrid fuzzers: AFL, AFLFast, FairFuzz, MOPT, QSYM, and Angora. Statistically, TortoiseFuzz found more vulnerabilities than 5 out of 6 fuzzers (AFL, AFLFast, FairFuzz, MOPT, and Angora), and it had a comparable result to QSYM yet only consumed around 2% of QSYM's memory usage on average. We also compared coverage accounting metrics with two other metrics, AFL-Sensitive and LEOPARD, and TortoiseFuzz performed significantly better than both metrics in finding vulnerabilities. Furthermore, we applied the coverage accounting metrics to QSYM and noticed that coverage accounting helps increase the number of discovered vulnerabilities by 28.6% on average. TortoiseFuzz found 20 zero-day vulnerabilities with 15 confirmed with CVE identifications.

show abstract

PTfuzz: Guided Fuzzing With Processor Trace Feedback

Cited by 57 publications

References 16 publications

Full-Speed Fuzzing: Reducing Fuzzing Overhead through Coverage-Guided Tracing

Full-Speed Fuzzing: Reducing Fuzzing Overhead through Coverage-Guided Tracing

PTrix

Not All Coverage Measurements Are Equal: Fuzzing by Coverage Accounting for Input Prioritization

Contact Info

Product

Resources

About