Interview

Will new Sulley framework take fuzzing to next level?

Bill Brenner, Senior News Writer
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?

    Requires Free Membership to View

    Login

Exclusive interview: Pedram Amini
Security Wire Weekly: Pedram Amini: TippingPoint security researcher Pedram Amini explains why the Sulley fuzzing framework is an important development in the quest to uncover software vulnerabilities.

>>>>Download MP3 | Subscribe to Security Wire Weekly
The majority of fuzzers are one-off scripts, hacks or tools to test a specific implementation or target, whereas fuzzing frameworks, such as Peach and SPIKE, are more designed to create a foundation you can build new fuzzers on top of. A main shortcoming we've come across [with fuzzing in general] is the inability to fuzz in depth. A lot of fuzzers will only test the surface of the application, and it's difficult to create a fuzzer that will do a really thorough audit. Sulley was developed so you can easily break apart the tasks of creating a more complicated fuzzer and taking the process deeper. Another problem: When you write a fuzzer and it causes a crash or detects some fault in the target, that's pretty much the end of the game. It's up to you to figure out what that fault was and how you reset your environment to continue fuzzing through all your possible test cases. One of the biggest advantages of Sulley is that it's fully automated. I can set it up on a Friday afternoon and it'll run though the entire weekend. Whether it finds one, 50 or 5,000 crashes every single time it'll restore the target to a healthy state and then continue to go through all your other test cases. It'll complete the audit while you're away from the system. Where did the name Sulley come from?
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.
History of fuzzing:

1989: Professor Barton Miller (UW-Madison) applies "fuzzing" to test robustness of UNIX applications

2002: SPIKE released by Dave Aitel of Immunity

2002: Oulu University releases SNMP test suite, leading to the discovery of many vulnerabilities

2005: Commercial fuzzers introduced [Codenomicon, Mu Security, for example]

2006: Numerous client side fuzzers emerge [ActiveX: COM Raider and AxMan; HTML/CSS: Hamachi and CSSDIE]

2007: Sulley advanced fuzzing framework released

Source: Pedram Amini, TippingPoint
What are some of the more interesting discoveries you've made using Sulley?
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.

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top