An open source fuzzing tool developed by researchers at the Software Reliability Group of Imperial College London aims to solve some of the thorny problems of testing network applications.
SnapFuzz uses a series of techniques to speed up the testing of network protocols and overcome the timin constraints and other limitations that make it difficult to fuzz networking applications.
While SnapFuzz is still in its early stages, it shows promising results and its developers hope it will soon become a mainstay in the toolbox for testing networking applications.
Fuzzing is a popular way to test and discover bugs in software. However, network applications can be tricky to fuzz properly, say Anastasios Andronidis and Cristian Cadar, the authors of the SnapFuzz paper.
“Most network applications are stateful,” the researchers told The Daily Swig. “Stateful applications have side effects, that is, they perform operations that change the environment of the application, and these changes can interfere with the fuzzing process.”
For example, network applications require writing data to the file system or exchanging messages over the network with other applications.
“No one wants random emails to be sent to your colleagues because of a fuzzing campaign. So proper isolation is mandatory,” the authors said.
Furthermore, the researchers say, these side effects can interfere with the fuzzing process, which might incorrectly infer that a given message exchange reaches a certain part of the code, when in fact it is the side effects of a previous fuzzing iteration that trigger the behavior.
“Efficiently resetting the state in-between fuzzing iterations is important,” Andronidis and Cadar said.
State-of-the-art fuzzers for network applications, such as AFLNet, require specialized test harnesses that manually reset the state between iterations, add time delays to synchronize the network application with the fuzzer, and specify the point in the code where the application has finished its initialization.
“These are time-consuming to write and can be quite fragile. For instance, we had to readjust some time delays when switching to a different machine,” the researchers said.
The researchers also noticed that application developers often add delays, such as gracefully terminating a server. “These are fine in a production environment but are unfriendly to the high-performance throughput required by fuzzers,” Andronidis and Cadar said.
SnapFuzz builds on top of AFLNet and adds several features that address manual configuration and performance issues found in other fuzzing tools.
The SnapFuzz protocol automatically transforms all asynchronous networking communications into much more efficient synchronous communication based on UNIX domain sockets.
An in-memory copy-on-write file system automatically resets the filesystem state without requiring user intervention. And the researchers also developed a method to automatically infer the point where the application has finished initialization, which significantly speeds up fuzzing.
“To achieve all these, SnapFuzz leverages binary rewriting. This technique efficiently intercepts all system calls of the application under fuzzing and gives full control to SnapFuzz to dictate how the application should interact with its environment, and particularly the fuzzer,” Andronidis and Cadar said.
The researchers used SnapFuzz to test five popular networking applications: LightFTP, TinyDTLS, Dnsmasq, LIVE555, and Dcmqrscp. They were able to achieve impressive speed improvements of 60x, 40x, 30x, 25x, and 8x, respectively.
“With respect to ease of use, we were able to eliminate the need for custom cleanup scripts and manually-specified time delays, which can be hard to get right,” Andronidis and Cadar said.
For the moment, SnapFuzz is a new project and a work in progress that has only been tested on well-established benchmarks.
“It is our top priority to extend our work to more benchmarks and the latest versions of popular networking projects like Redis and Memcached, and push for adoption into industry, starting with companies that are already fuzzing their network applications,” Andronidis and Cadar said.