Fuzzing 101: Why Bug Hunters Still Love It After All These Years

When you're in the kitchen and throw pasta against the wall, it might stick so that you can tell whether it's cooked. When you're in computer security and you throw things against a target's "wall," they might do nothing ... they might blow up the wall. Or they might land you in a different place entirely. That's the allure — and the danger — of "fuzzing" as a research tool.

To understand what fuzzing is and why it's so valuable, we go back 30 years to "An Empirical Study of the Reliability of UNIX Utilities," a paper written by lead author Barton P. Miller, the "father of fuzzing." In that paper, and in its 1995 follow-up "Fuzz Revisited," Barton and his co-authors present the technique of throwing unanticipated input at utilities and programs to see what happens.

In the original paper, Barton wrote that the idea of fuzzing was born in line noise from a dial-up network connection. When random characters in the exchange caused a program to crash, it led researchers to wonder whether a tool generating random input strings could be valuable when looking at application security and reliability. As it turns out, it can be quite valuable — and the method can aid in discovering a host of vulnerabilities and errors.

What Can Fuzzing Discover?
The errors and vulnerabilities that fuzzing can discover tend to fall into four broad categories: invalid inputs, memory leaks, assertion failures, and incorrect results or connections. A separate area of fuzzing is used in credential stuffing attacks. Each can result in its own form of insecurity for the application or system owner.

Invalid input: In almost every application that accepts user input, the program expects the input to be in a particular format. But what happens if, for example, a text string is entered into a date field? What happens if a series of emojis is entered into a name field? In both cases, type-checking functions should throw away the input and issue an error, but rushed developers don't always include robust type-checking in their code. That's when the vulnerabilities begin.

Memory leaks: Memory leaks — when applications use memory for instructions and data, they're supposed to clean up after themselves, releasing the memory to be used again and keeping everything within the nice, neat, logical boundaries that computers love. Unfortunately, some programmers don't follow best practices and some programming languages thwart the best memory management efforts. Because of this, over time, memory becomes cluttered with stray data, information is stored where it shouldn't be, and havoc ensues. Stuffing excessively large input into applications can speed up the process if good input-validation isn't in place, and fuzzing can help figure out where those opportunities for mayhem reside.

Assertion failure: Many applications assume that you've followed a logical path to get to a given point. That tends to mean that qualifications have been met and states set before you do what you're doing now. But what if those states haven't been set and those qualifications haven't been met? If you're still allowed to proceed, then an assertion failure has occurred — something the program was expecting hasn't yet happened. Fuzzing is a great way to see if you can "skip the line" and get somewhere you shouldn't be.

Unexpected connections: Fuzzing can help answer the question, "What if, instead of my first name, I entered a SQL command here?" Or, "What if I entered a URL where the application was expecting something else?" In each of these cases, if anything but a discarded input and error message result, then a vulnerability has been discovered.

Credential stuffing: Report after report show that human beings tend to rely on a handful of common, easily typed passwords for online accounts. And organizations tend to use a handful of formats for generating email addresses for employees. Attackers (or pen testers) can then try all of the common password types with each possible email address — statistically, they'll get at least a few successful logins for each organization. Of course, running through all of the permutations can take time, unless the attacker is using an automated tool for fuzzing credentials.

Fuzzing Tools
In order to truly explore each type of vulnerability, a researcher must try a variety of different possibilities for each targeted input field. It would take far too much time to do this manually, so a variety of different automated tools have been developed to make the process faster and easier.

There are a number of free tools available for fuzzing. Among them are:

While not a simple fuzzing tool, Google OSS-fuzz is used by many researchers and can be a valuable tool for learning a complete research process around fuzzing. And it's important to note that Barton has maintained a web page about fuzzing, including a link to download all the software, definitions, and targets in his original research, at the University of Wisconsin-Madison.

Related Content: