The Future of Security Gets Fuzzy

Testing is a consistently underappreciated part of software development. Comprehensive testing takes time away from development and delays product releases, both anathemas to developers. And yet when a program turns out to be low-quality, you have to know that on the inside many people are whispering that the testing guys didnt do their job.

Ive been in the computer-testing business professionally since 1987, so I speak from experience when I say that the only thing better than a well-designed test is a well-designed test that can be extensively automated. A new class of testing tools may vastly increase the amount of automation possible in some important classes of testing.

"Fuzzing" is a testing concept that has been in use for many years, mostly with in-house testing departments. The basic concept is to send unexpected input into a program to see if it reacts properly. The granddaddy of fuzzers is Fuzz from the University of Wisconsin-Madison.

I remember the first public fuzzer I heard of: It was an HTML fuzzer that created strange tags—some malformed, some just bizarre—and fed them into browsers. It found lots of errors and exploitable vulnerabilities in Internet Explorer and even more in Firefox.

And yet this fuzzer, like most of the public efforts so far, was a naive one, with a high degree of randomness in the input. An intelligent fuzzer isnt random; its actually quite deliberate, and it probably avoids genuinely malformed input.

This is what Beyond Security, a vendor of security tools and services, is working on. The fuzzing tool it is working on, called beSTORM, focuses on network-enabled applications and models the protocols used to communicate with them in a graph using a language they developed similar to BNF (Backus-Naur Form) notation. (A "graph" in computer science isnt bars and lines, its a complex data structure with nodes and edges between them.)

Check out eWEEK.coms for the latest news, reviews and analysis about productivity and business solutions.

beSTORM exercises the protocol with specific emphasis given on technically legal but functionally erroneous and stressful cases. A simple example would be where the protocol calls for a length value followed by a stream of data. What happens if you send x for the length byte, but then send x*2 bytes? Or x/2 bytes? What if the application is expecting a file name and you send it characters not valid in one? What if you do illogical things with protocol sequence numbers?

Next page: More fuzzing logic.