This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Security

Fuzz testing with zzuf

By Joe Barr on July 26, 2007 (9:00:00 AM)

Share    Print    Comments   

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:

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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:

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXZXXXXXXXXXXXXXZYXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXxXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXZXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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.

Share    Print    Comments   

Comments

on Fuzz testing with zzuf

Note: Comments are owned by the poster. We are not responsible for their content.

Fuzz testing with zzuf

Posted by: Anonymous [ip: 208.181.115.2] on July 26, 2007 04:29 PM
"While no manuals or guides are available, the man page created during the installation is packed with information on how to use zzuf."



tell me again what "man" in man page is short for?

#

Re: Fuzz testing with zzuf

Posted by: Anonymous [ip: 72.236.163.214] on January 24, 2008 03:22 PM
"the biggest thing to happen in IT security in quite awhile" may be a bit of an overstatement since fuzz testing has been around for a while, but a good article none the less.
<a href="http://www.javasigns.com/decals">car decals</a>

#

Fuzz testing with zzuf

Posted by: Joe Barr on July 26, 2007 05:36 PM
Cute, but there is a big difference between a manual and man.

#

Re: Fuzz testing with zzuf

Posted by: Anonymous [ip: 208.181.115.2] on July 26, 2007 07:27 PM
sorry, wasn't meant as a troll. I suspect we have very different expectations for the quality of man pages though, since you've confirmed that is what you meant to say.



~Ryan

(not an AC, I just don't feel like making an account right now)

#

Fuzz testing with zzuf

Posted by: Anonymous [ip: 75.167.6.165] on July 26, 2007 06:34 PM
First, I am happy that you made an article about this showing how to use fuzz testers. Second, I'd like to correct you on a few points. Fuzz testing has been around for years -- at least since 1989 when it was demonstrated at UW-Madison by Barton Miller. So it's not the biggest thing it IT security in quite a while because it's been around for nearly 20 years. The original program was called fuzz and it's still in use but zzuf came around with a following and new features and I applaud Sam for his efforts and hope he continues to develop an advanced fuzz tester/testing suite.

Also, please don't blame users for bad input in forms which should be developed to only accept certain types of data. There are many better examples of stupid user input.

Sorry to troll.

#

Fuzz testing with zzuf

Posted by: Joe Barr on July 26, 2007 07:32 PM
Not a troll in my book, thanks for the correction on the origination of fuzz testing, and the fuzz program itself. I would like to learn more about that.

Fuzz testing has only crept into my consciousness because of the success it has had in discovering new vulnerabilities. I was a professional programmer from 1974 to 2001, and I never saw it or heard of it at all during my career. The big thing in testing as I was leaving the coding world was the "code to test" philosophy. Before that, the only big change I saw was in the popularization of IBM's "Black Team" approach, which tried to break apps instead of the kind of testing developers had always done, which tried to prove they worked.

As far as lame/stupid users are concerned, those comments are made based on my experience as a programmer, coding from specs which say "this field will contain blah blah blah" and then being unhappy over testing which didn't conform to the specs I was coding from. I think it's a valid analogy for fuzz testing.

I would like to hear more from you on this subject, please drop me a line if you like, or comment again here.

Thanks,
joe Barr

#

Fuzz testing with zzuf

Posted by: Sam Hocevar on July 27, 2007 08:45 AM
Just a note about the Xlib error: the reason xine does not work straightforward with zzuf is because X applications try to open ~/.Xauthority to connect to the X server, and of course that file gets fuzzed by default like any other (run "zzuf -d xclock" to see what happens) so the contents of the cookie are corrupt.



The reason it works when doing "xhost local:root" is because the invalid cookie is simply ignored since another authentication method is available. This is not the preferred way to fix it. To avoid specifically fuzzing ~/.Xauthority, use the "-E .Xauthority" flag. But since GUI apps may load a lot of other files such as icons, fonts etc., you'll probably prefer the "-c" flag, or something like "-I /media".

#

Re: Fuzz testing with zzuf

Posted by: Joe Barr on July 27, 2007 02:39 PM
Thanks, Sam, for clearing that up.

#

Fuzz testing with zzuf

Posted by: Anonymous [ip: 62.251.99.82] on July 27, 2007 10:53 AM
Useful! Yesterday already I saw people working with zuff to stress-test strigi and committing fixes.

Boudewijn

#

Fuzz testing with zzuf

Posted by: Anonymous [ip: 67.106.39.131] on October 04, 2007 08:18 PM
"We can thank stupid users for the fuzz testing craze"

This is garbage. Fuzz testing isn't needed or popular because of stupid users, it is needed because of decades of poor security practices by developers and educators. Suggesting that accepting invalid input is the user's fault is arrogant, foolish, and detrimental to both the Linux community and the security community.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya