Pedram Amini, head of TippingPoint's security research group, has been busy with Aaron Portnoy, touting a new tool for functional protocol testing (also known as "black-box testing" or "fuzzing,"). He co-wrote the recently-released book "Fuzzing: Brute Force Vulnerability Discovery" along with Michael Sutton and Adam Greene, and he used his stage time at the Black Hat USA 2007 Briefings in Las Vegas last month to unveil the new Sulley fuzzing framework. In this Q&A, he talks about the book and explains how the Sulley framework will take fuzzing to the next level.
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?
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
Where did the name Sulley come from?
Amini: 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
Amini: 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.
What are some of the more interesting discoveries you've made using Sulley?
Amini: 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?
Amini: 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.
Amini: 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.