Posted on by Toolsin
Hi folks. I've been involved in a fuzzing effort at CERT. One of the ways that I've been able to discover vulnerabilities is through "dumb" or mutational fuzzing. We have developed a framework for performing automated dumb fuzzing. Today we are releasing a simplified version of automated dumb fuzzing, called the Basic Fuzzing Framework (BFF).
Dranzer was one of our first fuzz testing projects. By performing automated smart fuzz testing of ActiveX controls, I was able to discover thousands of vulnerabilities. Luckily, Microsoft has made some improvements to Internet Explorer to help minimize the impact of ActiveX vulnerabilities.
Another technique that I've used for discovering vulnerabilities is dumb fuzzing. Don't let the name fool you. Dumb fuzzing has the advantage of being more universal than smart fuzzing. Dranzer is limited in that it tests only ActiveX controls; with dumb fuzzing, you can switch targets easily after your dumb fuzzing environment is complete.
The Basic Fuzzing Framework (BFF) consists of two main parts:
The virtual machine is a stripped-down Debian installation with the following modifications:
sudois configured to not prompt for a password.
stripis symlinked to
/bin/true, which prevents symbols from being removed when an application is built.
The fuzzer used by the BFF is Sam Hocevar's excellent zzuf application. zzuf was chosen for its deterministic behavior, number of features, and lightweight size. By invoking zzuf from a script (
zzuf.pl), we are able to automate additional aspects of a fuzzing run:
zzuf.plwill determine if a crash has been encountered before. By default, duplicate crashes are discarded.
zzuf.pl reads the configuration options from the
zzuf.cfg file. This file contains all of the parameters relevant to the current fuzz run, such as the target program and syntax, the seed file to be mutated, and how long the target application should be allowed to run per execution. The configuration file is copied to the guest OS when a fuzzing run has started. The zzuf script will periodically save its current progress within a fuzzing run as well. These two features work together to allow the fuzzing VM to be rebooted at any point, allowing the VM to resume fuzzing at the last stop point. The fuzzing script also periodically touches the
/tmp/fuzzing file. A linux software watchdog will check for the age of this file; and, if it is older than the specified amount of time, the VM will automatically be rebooted. Because some strange things can happen during a fuzzing run, this robustness is necessary for full automation.
The BFF is preconfigured to automatically begin fuzzing a very old version of ImageMagick. A debug build of ImageMagic 5.2.0 is installed on the system,
zzuf.cfg is set up with the fuzzing parameters, and a simple Netpbm seed file is included. When the machine is powered on, it will automatically log in and
zzuf.pl will invoke the zzuf fuzzer. ImageMagick's
convert program will repeatedly execute, attempting to convert the seed file into a bitmap file. The way that zzuf works is that each time the application is launched, the seed file will be mangled in a certain way. The goal of fuzzing is to determine malformed input that causes the target application to crash. The zzuf.pl script takes this one step further by collecting additional information about the crashes. Cases that are determined to be unique are saved.
To begin fuzzing on your own, simply follow these steps:
DebianFuzz.zipto a directory of your choice.
You may need to verify that the shared folder is enabled in the VM preferences. Other virtualization products may work with some additional configuration. See the README.txt file in
scripts.zip for more details.
P.S. If you are interested in this sort of stuff, check out our job opportunities.