Investigating a Project �& Picking a Function to Fuzz

Fuzz Dojo

Steven Wirsz

Arizona State University

Start with a Simple Project

Fuzz driver difficulty is determined by more than the rated difficulty!

​

Difficulty Factors:

• Existing Drivers: simple, medium, complex
• Low LOC counts
• Fast Compile Times
• Low or Mid-Range Static Code Coverage (more uncovered code)

​

Any project you are personally familiar with!

​

#

Picking a Function to Fuzz

Important Criteria:

• Must make sense to fuzz: understand what the function does!�
• Must be on an attack surface: processes untrusted input�
• Must tolerate any type of input: not exit or crash�
• Control dependencies: know sequence of functions is executed�
• Date dependencies: understand normal input to its parameters

#

Fuzz Driver Creation Process

Target Identification

• Read Training Description
• Google the project name
• Search for API details, unit tests, interfaces
• Study Existing Fuzz Drivers

Program Analysis

• Function Selection
• Identify required input values
• Identify functional dependencies
• Control-Flow Analysis
• Data-Flow Analysis

�Fuzz Driver Creation

​

#

Good Fuzz Driver Development Methodology

A good harness achieves both high code coverage and a high rate of bug identification.

To achieve this, you need:

• Understand the CodeBase of the target code�
• Optimize for code coverage, cyclomatic complexity�
• Deterministic Behavior (No multithreading, no random)�
• Avoid Intentional Crashes

​

#

New Fuzz Driver or Expand Existing Driver?

New Fuzz Driver:

• Untouched code
• Unfuzzed interface
• Large codebases with complex functions / dependencies

​

Expand Existing Fuzz Driver:

• Fix blocked code (explore the Fuzz Introspector report)
• Minor improvements
• Smaller codebases calling multiple simple functions

​

​

#

Improving Your Fuzz Driver [1/3]

Checklist:

• Run a fuzz introspector report and view the call tree, looking at unreached sections, and determine why these areas are not being hit.
• Vary the structure and constraints on your input data. Are many runs failing early due to invalid data types?
• Could different parameter combinations hit code not currently being reached?
• Examine the functions being called. Could you call functions higher on the call tree to reach more code?
• Experiment with different sanitizers and check for hidden errors, revealed by fuzzing runs with address, undefined, thread, and memory sanitizers.

#

Improving Your Fuzz Driver [2/3]

Checklist:

• Are you using a seed corpus? Can you make this corpus more diverse and also remove redundant samples?
• Could implementing additional preconditions be necessary to fulfill control dependencies needed for untouched code? I.E., do you need to open a file before you can read from it?
• Look for complex branch conditions involving checksums, hashes, or magic values. Could you add custom comparators to your fuzz driver, or bypass these checks by calling functions beyond them?
• Are timeouts or memory errors occurring when running your fuzz driver?

#

Improving Your Fuzz Driver [3/3]

Checklist:

• Can you improve performance by testing and optimizing your code?
• Do you see the need to extend your fuzz driver by calling additional functions or by creating a different new fuzz driver entirely?

​

#

Other Tricks

Search GitHub or blog posts for different projects with a similar theme or structure and adopt their fuzz drivers for your project

​

Search existing OSS-Fuzz drivers:

https://github.com/search?q=repo%3Agoogle%2Foss-fuzz+path%3A%2F%5Eprojects%5C%2F%2F++AND+%28language%3AC%2B%2B+OR+language%3AC%29&type=code

​

​

#

More Time-Saving Tricks

Tweaking code and then regenerating coverage reports can be slow.

Compiling and then running your fuzz driver is much faster.

• Put Fuzzer into debugging mode, watch output
• Add print statements into the source code
• Create intentional crashes into the source code �(Example: null pointer dereference)

�The project source code is always available in the Fuzz Dojo under “Workspace”, or in the shell under /src-{sanitizer}

#

Online Reports

Browse code online on:

https://introspector.oss-fuzz.com/projects-overview

​

Github repository links

Project statistics

Code coverage of existing fuzz drivers

Browse source code coverage reports

#

Fuzz Introspector

Static analysis tools are useful to analyze source code complexity, function parameters, and finding functions high in the call tree to fuzz�

Fuzz Introspector reports can be generated manually or viewed online

• Evaluate the effectiveness of existing fuzz drivers or test new ones
• Troubleshoot sections of code the fuzz driver fails to reach
• List possible functions with high reach/complexity to create a new fuzz driver

​

​

#