Weaknesses in Fuzzers

Modeling Arbitrary Network Protocols

Let's leave host-based fuzzers for a moment. Although useful for identifying some basic properties of fuzzers , host-based vulnerabilities (also know as locals ) are a dime a dozen . The real meat is in finding vulnerabilities in programs that listen on TCP or UDP ports. These programs each use defined network protocols with which to communicate with each othersometimes documented, sometimes not.

Early fuzzer development was restricted largely to perl scripts and other attempts at emulating protocols while at the same time providing a way to mutate them. This collection of perl scripts leads to a large quantity of protocol-specific fuzzersone fuzzer for SNMP, one fuzzer for HTTP, one fuzzer for SMTP, and so on, ad infinitum. But what if SMTP, or some other proprietary protocol, is tunneled over HTTP?

The basic problem then, is one of modeling a network protocol in such a way that it is possible to include it in another network protocol quickly and easily and make sure it will do a good job of covering the target program's code in a way that will find many bugs. This usually involves replacing strings with longer strings or different strings and replacing integers with larger integers. No two fuzzers find the same set of bugs . Even if a fuzzer could cover all the code, it may not cover it all in the right order or with the right variables set. Later in this chapter, we'll examine a technology that follows these goals, but first, we'll look at other fuzzer technologies that are also quite useful.