T-Fuzz: Fuzzing by Program Transformation

Abstract

Fuzzing is a simple yet effective approach to discover software bugs utilizing randomly generated inputs. However, it is limited by coverage and cannot find bugs hidden in deep execution paths of the program because the randomly generated inputs fail complex sanity checks, e.g., checks on magic values, checksums, or hashes.To improve coverage, existing approaches rely on imprecise heuristics or complex input mutation techniques (e.g., symbolic execution or taint analysis) to bypass sanity checks. Our novel method tackles coverage from a different angle: by removing sanity checks in the target program. T-Fuzz leverages a coverage guided fuzzer to generate inputs. Whenever the fuzzer can no longer trigger new code paths, a light-weight, dynamic tracing based technique detects the input checks that the fuzzergenerated inputs fail. These checks are then removed from the target program. Fuzzing then continues on the transformed program, allowing the code protected by the removed checks to be triggered and potential bugs discovered.Fuzzing transformed programs to find bugs poses two challenges: (1) removal of checks leads to over-approximation and false positives, and (2) even for true bugs, the crashing input on the transformed program may not trigger the bug in the original program. As an auxiliary post-processing step, T-Fuzz leverages a symbolic execution-based approach to filter out false positives and reproduce true bugs in the original program.By transforming the program as well as mutating the input, T-Fuzz covers more code and finds more true bugs than any existing technique. We have evaluated T-Fuzz on the DARPA Cyber Grand Challenge dataset, LAVA-M dataset and 4 real-world programs (pngfix, tiffinfo, magick and pdftohtml). For the CGC dataset, T-Fuzz finds bugs in 166 binaries, Driller in 121, and AFL in 105. In addition, found 3 new bugs in previouslyfuzzed programs and libraries.Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.

Smart Greybox Fuzzing

“…Our work builds on coverage-based greybox fuzzing (CGF) [31], [37], which is a popular and effective approach for software vulnerability detection. The AFL fuzzer [31] and its extensions [1], [2], [7], [11], [17], [18], [21], [27] constitute the most widely used embodiment of CGF. CGF is a promising middle ground between blackbox and whitebox fuzzing.…”

HotFuzz: Discovering Algorithmic Denial-of-Service Vulnerabilities Through Guided Micro-Fuzzing

“…Prior work has seeded fuzzing by replaying sequences of kernel API calls [25], commands from Android apps to smart IoT Devices [18], and input provided by human assistants [55]. Recent techniques for improving code coverage during fuzz testing include introducing selective symbolic execution [58], control-and data-flow analysis on the program under test [50], reducing collisions in code coverage measurements [23], and altering the program under test [46]. Prior work applies existing fuzz testers to discover AC vulnerabilities in whole programs [37], [47], and in Java programs by combining fuzz testing with symbolic execution [43] or seeding black box fuzzing with information taken from program traces [40].…”

“…Indeed, these tools are evaluated by the slowdown they can achieve for a given program, as opposed to the amount of code they successfully cover. Achieving high code coverage on any program under test is a notoriously difficult task because common program patterns like comparing input to magic values or checksum tests are difficult to bypass using fuzzing alone, although program transformation tricks like splitting each comparison into a series of one byte comparisons [36] or simply removing them from the program [46] can improve coverage. Augmenting fuzzing with advanced techniques like taint analysis [50] or symbolic execution [44], [58] helps overcome these fuzzing roadblocks, and RedQueen [12] showed how advanced tracing hardware can emulate these more heavyweight techniques by providing a fuzzer with enough information to establish correspondence between program inputs and internal program state.…”

Matryoshka

“…Steelix [26] and REDQUEEN [4] detect magic bytes checking and infer their input offsets to solve them without taint analysis. T-Fuzz ignores input checks in the original program and leverages symbolic execution to filter false positives and reproduce true bugs [28]. TaintScopre fixs checksum values in the generated inputs using symbolic execution [37].…”

“…Taintscope [37] uses taint tracking to infer checksum-handling code and bypasses these checks using control flow alteration since these checks are hard to satisfy when mutating the input. T-Fuzz [28] detects complex checks without taint tracking. Both approaches use symbolic execution to generate valid input that would solve target constraints.…”