An Architecture for Exploiting Native User-Land Checkpoint-Restart to Improve Fuzzing

TL;DR

This paper introduces a novel architecture that leverages native user-land checkpointing to enable attaching fuzzers after application start, significantly improving fuzzing efficiency and flexibility by allowing deeper execution point fuzzing and parallel testing.

Contribution

It proposes a new testing architecture that integrates native checkpointing with fuzzing, enabling post-start attachment and deeper execution point fuzzing, which was difficult with traditional methods.

Findings

Reduces fuzzing startup time by using checkpoints

Enables fuzzing from deeper execution points

Supports parallel testing with multiple checkpoints

Abstract

Fuzzing is one of the most popular and widely used techniques to find vulnerabilities in any application. Fuzzers are fast enough, but they still spend a good portion of time to restart a crashed application and then fuzz it from the beginning. Fuzzing an application from a point deeper in the execution is also important. To do this, a user needs to take a snapshot of the program while fuzzing it on top of an emulator, virtual machine, or by utilizing a special kernel module to enable checkpointing. Even with this ability, it can be difficult to attach a fuzzer after restoring a checkpoint. As a result, most fuzzers leverage a form of fork-server design. We propose a novel testing architecture that allows users to attach a fuzzer after the program has started running. We do this by natively checkpointing the target application at a point of interest, and attaching the fuzzer after restoring the checkpoint. A fork-server may even be engaged at the point of restoration. This not only improves the throughput of the fuzzing campaign by minimizing startup time, but opens up a new way to fuzz applications. With this architecture, a user can take a series of checkpoints at points of interest, and run parallel tests to reduce the overall state-complexity of an individual test. Checkpoints allow us to begin fuzzing from a deeper point in the execution path, omitting prior execution from the required coverage path. This and other checkpointing techniques are described in the paper to help improve fuzzing.