More fuzzing logic

By Larry Seltzer  |  Posted 2006-02-06 Print this article Print

So why not do illegal things with the protocol, too? Why not just send a zillion FF bytes? First, proxy servers will usually block out transmissions that are illegal at the protocol level, so application handlers dont usually have to deal with them. Second, there are an infinite number of possible attacks of this type, and they dont usually result in anything of interest, so its a black hole from the testing standpoint.

Even while staying legal, there are test cases with a theoretically infinite series of possibilities. Consider an HTML <A> tag with multiple hrefs in it: <A href="sdfsdf" href="sdfsdf" href="sdfsdf"...> For purposes of practicality, you can cap the number of these at some very high value.

For advice on how to secure your network and applications, as well as the latest security news, visit Ziff Davis Internets Security IT Hub.

beSTORM is designed to be used in a development environment in concert with a debugger, in order to elicit errors in the application being tested, such as subtle overflows. This is a difficult task to do in a user environment, another problem with much testing. A large beta test, for example, is a good thing to do, but its not likely to find abusive error cases of the type beSTORM is designed to catch.

Thoroughly exercising a protocol can result in a very large number of test cases and a long test period, but the automation can minimize the impact. Beyond Security claims that beSTORM has optimizations that allow it to focus first on cases that are more likely to produce results. And even better, by dividing up the test cases into sections, the tests can be made parallel, and you can often get linear scalability just by adding systems to the test. This is one way to mitigate the testers dilemma I described above.

Fuzzing is not just about network applications. There are many classes of applications for which it is useful; consider database applications, where the database programming protocol could be fuzzed. My personal favorite is window messaging, the protocol on Windows and other GUIs wherein windows send messages to one another. Especially in Microsoft Windows, this has been the subject of much vulnerability research in the last few years, and attacks on them (called "shatter" attacks) have potential for privilege escalation.

A next-generation fuzzer could be an important tool, and could result in a period of rapid vulnerability exposure. In the longer term, as testing like this becomes routine, such errors could become rare, which is a delightful scenario. Today they are all too common. Fuzzing isnt the end game in testing, since it addresses only certain classes of errors, but the more testing we do, the better security generally will be.

Editors Note: This story was updated to correct the spelling of the beSTORM product name. We also changed the reference to the original fuzzing tool to Fuzz. Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at Security Center Editor Larry Seltzers Weblog. More from Larry Seltzer

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel