X
Business

Microsoft security guru: Get fuzzing

Microsoft security whiz Michael Howard is urging developers in the Windows ecosystem to adopt fuzz testing as a critical part of the software creation process, stressing that the use of fuzzers can dramatically reduce the number of potential security vulnerabilities.
Written by Ryan Naraine, Contributor
Orlando, Florida -- Microsoft security whiz Michael Howard is urging developers in the Windows ecosystem to adopt fuzz testing as a critical part of the software creation process, stressing that the use of fuzzers can dramatically reduce the number of potential security vulnerabilities.
Michael Howard

Howard, co-author of a book on Microsoft's mandatory SDL (Security Development Lifecycle), issued the call during a lively Q&A session with attendees at the TechEd 2007 conference here. "If you fuzz, your bug rates will drop pretty quickly. You'll get to a flat line quickly [of bugs found] very quickly, assuming you're fixing the bugs as you go along," Howard said.

"The bad guys are fuzzing [your products]. You should be fuzzing and finding those coding errors that be a security bug," he added.

Fuzzing is one of four elements in the "implementation" stage of the SDL and refers the use of structured but invalid inputs to software APIs to pinpoint errors and crashes. Since hackers are mastering the art of fuzzing to find security holes (HD Moore's Month of Browser Bugs was a public demo of the power of fuzzers), Howard suggests that software creators get familiar with the idea of using mangled data to trigger program crashes.

Howard, an outspoken blogger who once questioned the way Vista vulnerabilities are rated, used the talk to discuss the fallout from the animated cursor (.ani) attacks earlier this year and the defense-in-depth mitigations that helped protect Windows Vista users from the zero-day attacks.

Despite all the pen testing, code review, static analysis and fuzz testing efforts that went into Vista, Howard said everyone missed the animated cursor flaw -- and learned a valuable lesson on how critical things can fall through the cracks.

"One of the things we want our developers at Microsoft to understand is that you can't trust data. You need to understand what the bad guys can control and, if he can control a part of your code, what can he do with it. If he controls certain parts, that [can be] exploitable," Howard said.

In the aftermath of the attacks, Microsoft did a comprehensive review of the incident Howard dropped broad hints a few months ago about some major changes coming down the pike. Among the changes under consideration were additions to the list of banned API function calls, more aggressive checks for buffer overruns and enhancements to existing fuzz testing tools.

[ SEE: Microsoft mulling major changes to ward off .ANI-type flaws ]

At TechEd, Howard disclosed that the final recommendation to ban "memcpy" had been made. "I literally wrote that recommendation on the plane coming here. It's in the hands of the appropriate people and should go into effect later this year," Howard said.

His recommendation is to ban three API function calls -- memcpy, CopyMemory and RtlCopyMemory.

"We spend a lot of time understanding where the [security/hacker research] market is going and try to stay ahead of that. We're trying to think about what's happening next and that's why we do these root- cause analyses to figure out if there's a trend to what [vulnerabilities] people are finding."

Editorial standards