141 research outputs found
The Progress, Challenges, and Perspectives of Directed Greybox Fuzzing
Most greybox fuzzing tools are coverage-guided as code coverage is strongly
correlated with bug coverage. However, since most covered codes may not contain
bugs, blindly extending code coverage is less efficient, especially for corner
cases. Unlike coverage-guided greybox fuzzers who extend code coverage in an
undirected manner, a directed greybox fuzzer spends most of its time allocation
on reaching specific targets (e.g., the bug-prone zone) without wasting
resources stressing unrelated parts. Thus, directed greybox fuzzing (DGF) is
particularly suitable for scenarios such as patch testing, bug reproduction,
and specialist bug hunting. This paper studies DGF from a broader view, which
takes into account not only the location-directed type that targets specific
code parts, but also the behaviour-directed type that aims to expose abnormal
program behaviours. Herein, the first in-depth study of DGF is made based on
the investigation of 32 state-of-the-art fuzzers (78% were published after
2019) that are closely related to DGF. A thorough assessment of the collected
tools is conducted so as to systemise recent progress in this field. Finally,
it summarises the challenges and provides perspectives for future research.Comment: 16 pages, 4 figure
Greybox fuzzing time-intensive programs
We examine (directed) greybox fuzzing from a geometrical perspective, viewing
dissimilarities on inputs and on control flow graphs (with dynamical
statistics) as primitive objects of interest. We prototype and evaluate
GoExploreFuzz, a greybox fuzzer for time-intensive programs that incorporates
this perspective. The results indicate useful capabilities for greybox fuzzing
that have hitherto been underutilized, notably quantifying the diversity of
paths and autonomously tuning the "bandwidth" of mutations
Targeted Greybox Fuzzing with Static Lookahead Analysis
Automatic test generation typically aims to generate inputs that explore new
paths in the program under test in order to find bugs. Existing work has,
therefore, focused on guiding the exploration toward program parts that are
more likely to contain bugs by using an offline static analysis.
In this paper, we introduce a novel technique for targeted greybox fuzzing
using an online static analysis that guides the fuzzer toward a set of target
locations, for instance, located in recently modified parts of the program.
This is achieved by first semantically analyzing each program path that is
explored by an input in the fuzzer's test suite. The results of this analysis
are then used to control the fuzzer's specialized power schedule, which
determines how often to fuzz inputs from the test suite. We implemented our
technique by extending a state-of-the-art, industrial fuzzer for Ethereum smart
contracts and evaluate its effectiveness on 27 real-world benchmarks. Using an
online analysis is particularly suitable for the domain of smart contracts
since it does not require any code instrumentation---instrumentation to
contracts changes their semantics. Our experiments show that targeted fuzzing
significantly outperforms standard greybox fuzzing for reaching 83% of the
challenging target locations (up to 14x of median speed-up)
Harvey: A Greybox Fuzzer for Smart Contracts
We present Harvey, an industrial greybox fuzzer for smart contracts, which
are programs managing accounts on a blockchain. Greybox fuzzing is a
lightweight test-generation approach that effectively detects bugs and security
vulnerabilities. However, greybox fuzzers randomly mutate program inputs to
exercise new paths; this makes it challenging to cover code that is guarded by
narrow checks, which are satisfied by no more than a few input values.
Moreover, most real-world smart contracts transition through many different
states during their lifetime, e.g., for every bid in an auction. To explore
these states and thereby detect deep vulnerabilities, a greybox fuzzer would
need to generate sequences of contract transactions, e.g., by creating bids
from multiple users, while at the same time keeping the search space and test
suite tractable. In this experience paper, we explain how Harvey alleviates
both challenges with two key fuzzing techniques and distill the main lessons
learned. First, Harvey extends standard greybox fuzzing with a method for
predicting new inputs that are more likely to cover new paths or reveal
vulnerabilities in smart contracts. Second, it fuzzes transaction sequences in
a targeted and demand-driven way. We have evaluated our approach on 27
real-world contracts. Our experiments show that the underlying techniques
significantly increase Harvey's effectiveness in achieving high coverage and
detecting vulnerabilities, in most cases orders-of-magnitude faster; they also
reveal new insights about contract code.Comment: arXiv admin note: substantial text overlap with arXiv:1807.0787
FairFuzz: Targeting Rare Branches to Rapidly Increase Greybox Fuzz Testing Coverage
In recent years, fuzz testing has proven itself to be one of the most
effective techniques for finding correctness bugs and security vulnerabilities
in practice. One particular fuzz testing tool, American Fuzzy Lop or AFL, has
become popular thanks to its ease-of-use and bug-finding power. However, AFL
remains limited in the depth of program coverage it achieves, in particular
because it does not consider which parts of program inputs should not be
mutated in order to maintain deep program coverage. We propose an approach,
FairFuzz, that helps alleviate this limitation in two key steps. First,
FairFuzz automatically prioritizes inputs exercising rare parts of the program
under test. Second, it automatically adjusts the mutation of inputs so that the
mutated inputs are more likely to exercise these same rare parts of the
program. We conduct evaluation on real-world programs against state-of-the-art
versions of AFL, thoroughly repeating experiments to get good measures of
variability. We find that on certain benchmarks FairFuzz shows significant
coverage increases after 24 hours compared to state-of-the-art versions of AFL,
while on others it achieves high program coverage at a significantly faster
rate
Augmenting American Fuzzy Lop to Increase the Speed of Bug Detection
Whitebox fuzz testing is a vital part of the software testing process in the software development life cycle (SDLC). It is used for bug detection and security vulnerability checking as well. But current tools lack the ability to detect all the bugs and cover the entire code under test in a reasonable time. This study will explore some of the various whitebox fuzzing techniques and tools (AFL, SAGE, Driller, etc.) currently in use followed by a discussion of their strategies and the challenges facing them. One of the most popular state-of-the-art fuzzers, American Fuzzy Lop (AFL) will be discussed in detail and the modifications proposed to reduce the time required by it while functioning under QEMU emulation mode will be put forth. The study found that the AFL fuzzer can be sped up by injecting an intermediary layer of code in the Tiny Code Generator (TCG) that helps in translating blocks between the two architectures being used for testing. The modified version of AFL was able to find a mean 1.6 crashes more than the basic AFL running in QEMU mode. The study will then recommend future research avenues in the form of hybrid techniques to resolve the challenges faced by the state of the art fuzzers and create an optimal fuzzing tool. The motivation behind the study is to optimize the fuzzing process in order to reduce the time taken to perform software testing and produce robust, error-free software products
- …