As you noted in your Black Hat presentation last month, there are already plenty of fuzzing tools out there. Why...
was it important to create the Sulley fuzzing framework?
Someone on the team decided to name it after the fuzzy creature from Monsters Inc. Can any IT security professional use this tool or does it require more specialized skills to operate?
It's not a point-and-click tool. It requires some background and skills sets. You can't just take the tool, unwrap it and start running it. But we have gotten a lot of positive reviews from people in the fuzzing industry. The goal wasn't to create this as a commercial product. The goal was to find a way to uncover more vulnerabilities. But we are working in the background with the hope that one day we can have an appliance or a VMware image you can just run and access over a Web interface and use a point-and-click interface to build and launch a fuzzer.
One example was that we found a number of flaws in HP's OpenView products [ TPTI-07-14: HP OpenView Multiple Product Shared Trace Service Stack Overflow Vulnerabilities]. It has also been used to find vulnerabilities in SCADA systems and in Trend Micro programs. Is Sulley something that was conceived and designed as a TippingPoint product or is it meant to transcend vendors?
It's not at all a product and there are no plans to make it one. The motivation for building this came about a year and a half ago as we were testing TippingPoint products for holes. We purchased a big, expensive commercial fuzzer that had a lot of shortcomings. In the process of dealing with the frustrations of using this commercial tool, we decided we had to bite the bullet and build our own fuzzer for our own benefit. Six to eight months later, once we realized how effective it was, we decided to make it open source and invite some outside developers in to help out and to just share this with the rest of the industry. Talk about "Fuzzing: Brute Force Vulnerability Discovery," in terms of the message you, Sutton and Greene want people to come away with.
The book is structured with two goals in mind: It's very hands-on-oriented so you can learn how to build a fuzzer as much as how to use it. Part two of the book goes through a list of targets like Web services and command line applications. We give a background on each target and how you might go about automating the development of a tool to attack that target in a Unix or Windows environment. Another goal was to bring fuzzing to the attention of a larger industry, not just the security professionals. There's no reason why a developer can't be fuzzing his code during the software development lifecycle to reduce the number of bugs that will be present after the product is released.
Dig Deeper on Secure software development