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.

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.