The buzz about fuzzers

Writing perfect secure code is hard. Daniel J. Bernstein has probably come the closest to it in practical, publicly released software. With his almost maniacal drive for security perfection, he has written multitudes of software that remain unbroken.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

There was a reported bug in one of his mailing programs, but it was so obscure and unlikely to be used in real life that he refused to call it a security bug. You might be able to argue that point, but the fact is, that's only one obscure bug over many years of programming. Not many professional programmers can say that.

Then again, I haven’t seen him manage a large team of programmers writing millions of lines of code. I suspect that making a large team of programmers as passionate and careful about security programming as he is would prove more difficult than writing perfect code.

Many studies say that there are five to 10 bugs (albeit not all security holes) per 1,000 lines of code in the average program. No matter how hard you try to get rid of them, no amount of testing can beat every hacker in the world banging on your program. Just ask David LeBlanc, chief software architect for Webroot Software. He is the co-author of the best-selling book Writing Secure Code and was a leading security architect at Microsoft for six years.

David is a geek’s geek. When he starts talking about buffer overflows and how to prevent them, not many people argue -- he knows his stuff. During his tenure at Microsoft, he was instrumental in getting the company truly focused on more secure coding. The results of his efforts can be seen in Microsoft Office (been bothered by a macro virus lately?), Windows Server 2003, and IIS 6.0. Analysts have lauded all of them for their overall security and reliability, especially when compared to previous versions of the same.

David is passionate about secure coding. He taught Microsoft programmers how to write securely and gave them tools and methodologies to help. The process involved education, self review, peer review, team review, external review, and automated security tools. But try as he might, David couldn’t prevent all coding mistakes and buffer overflows.

This perplexed me a bit, because David’s as bright as they come. Working for Microsoft on a high-visibility product, he had senior management’s attention and support; and he had probably what comes as close to an unlimited budget as any of us will ever see in the private sector.

I asked David how those coding mistakes slipped by. Was it a lack of perfect tools, or was it human error?

As I should have guessed, he says both. Humans are ultimately to blame, but better tools would have helped when reviewing and approving the vast amount of code. There is just no way for a human being to catch every possible mistake that could go wrong with every line, especially when the coders are writing under a competitive deadline on complex software. That's where fuzzers can help.

A fuzzer is a software program or script designed to look for possible errors in a piece of programming code or script. The ultimate fuzzer would look for every input variable and try every possible allowable combination of input, hoping to find buffer overflows and unhandled coding errors. Fuzzers find most of the buffer overflows these days, and white- and black-hat hackers alike use them.

Professional bug hunters, such as eEye and Core Security Technologies (maker of penetration-testing tool Core Impact) find many of their bugs using fuzzers. A professional hacker friend of mine who works for the U.S. government (I’d tell you who he is, but then I’d have to kill you) agrees that fuzzing finds most of the bugs. He says fuzzers work so well that the hard part in writing a fuzzer is trying to give it intelligence, so it knows when it finds an error instead of relying on human intervention and observation.

There are many free fuzzers available on the Internet. For example, iDefense’s Filefuzz program lets you malform many different Windows file formats. SPIKEfile does the same thing for Linux files. The HTML Manglizer fuzzes HTML parsers. It was responsible for finding the Download.ject exploit (thanks to Karl Levinson for this one). Many fuzzers, such as Smudge, are written in scripting languages like Python.

With that said, even fuzzer-reviewed code will still contain mistakes, because fuzzers are written by humans and can implement only the mistakes that a human could possibly think of.

If you are in charge of coding anything, you need to program securely. Get educated in secure coding, follow a secure coding methodology, and consider using an automated program to help find the bugs. A good fuzzer might help. If you don’t use one, there's a good chance a hacker will.

Stay tuned -- I’ll have more details on my conversation with David LeBlanc in my next column.