Fuzz testing with zzuf


Author: Joe Barr

Fuzz testing, which uses random input to test software for bugs, has been the biggest thing to happen in IT security in quite awhile. Now you can quickly and easily direct your own fuzz testing ops, thanks to a cool little program called zzuf.

We can thank stupid users for the fuzz testing craze — users who enter dates where dollar amounts are supposed to go, or digits where their names belong, or a ZIP code where a Social Security number is expected. Their lameness often results in instant breakage — segfaults, overruns, all manner of crashes. And some of those crashes are perfect for exploiting, allowing black hats to gain access to systems or data — like the Wi-Fi vulnerabilities that were almost disclosed at BlackHat about this time last year, for example, which were discovered by fuzz testing the Wi-Fi drivers with unexpected data.

Fuzz testing throws anything and everything, and sometimes nothing at all, at applications expecting data of a certain size, shape, or format. Many programs are more stable and secure today because of the hidden flaws found with fuzz testing.

Zzuf, according to the project’s home page, started its life as a tool to find bugs in the VLC media player software. It has since been expanded for broader use.

Installing zzuf is a straightforward exercise. After downloading zzuf-0.9.tar.gz from the project page and decompressing the tarball, enter the resulting zzuf-0.9 subdirectory and run the ./bootstrap script, followed by the standard ./configure, make, and sudo make install. I installed zzuf on Ubuntu Feisty Fawn.

The build process creates the zzuf executable and another program called zzcat, along with a script called testsuite.sh. I executed the script, and watched as it ran through more than 200 different tests. The program’s author, Debian Project Leader Sam Hocevar, explains:

The testsuite acts both as a regression testsuite and a check whether zzuf has a chance of working properly on the current operating system. It runs a few known programs (cat, sed, grep) and zzcat (a custom program that does a lot of different file descriptor operations such as reading random bytes, seeking at illegal positions, mmap()ing the file…) on various test files through zzuf. If all programs give the same answer, it means all important library calls were properly intercepted by zzuf.

Putting it to the test

Here is an example of zzuf usage at its simplest level, borrowed from a presentation on zzuf that Hocevar has online. To see how it works, we will fuzz the input to cat as it dumps a simple text file to the screen.

Assume we have a text file named test.txt that contains the following data:


If you simply enter the command cat test.txt, the text appears in your console just as you see it above. But look at what happens when we fuzz cat’s input by entering zzuf cat test.txt instead:


Repeat that command several times, and note that the resulting output is exactly the same each time. That’s an important aspect of zzuf — the ability to reproduce the exact test that causes a specific outcome. No matter how complex your test, you can repeat it to reveal those elusive and evasive bugs you’re hunting.

Of course zzuf can do much more complex testing than the example using cat. While no manuals or guides are available, the man page created during the installation is packed with information on how to use zzuf. Running zzuf with the -h option gives you a help page with a brief explanation of its features.

When I first tried to use zzuf to test Xine, I could get no further than the following error messages:

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

Google led me to a cure for this problem. All it took was to precede the zzuf test with the command xhost local:root, which magically allowed zzuf to connect to the X server on my Ubuntu installation.

Zzuf may still be in beta, but if you’re curious about fuzz testing and want to try it against your own favorite apps, it’s good to go now. If you’re not yet curious about fuzz testing, you should be. It might very well be the technique used to crack your applications — whether it’s you finding exploitable vulnerabilities in the code, or someone else.


  • Security
  • Programming