What do You do With your Fuzzing Results?

Depending on what category of fuzz tester you are, here are some simple recommendations for how to best deal with finding a bug or security flaw.

Vendor or Developer

If the bug was discovered internally as a part of normal QA or a security audit, the appropriate test case should be logged and documented so that the responsible developers can address the root cause of the flaw. All historical test cases should be retested through regression testing to ensure none of the flaws creep back in to subsequent builds.

In-house Corporate Security Tester

If you a customer or potential customer of a product, and find a security flaw in it, the first thing you should do is share the information with your support or sales engineer. More and more vendors are starting to form assigned security response groups whose job is to receive these types of issues from the outside world. The response and receptiveness to your bug report will speak volumes as to the maturity of that vendor's in-house security processes.

A decent set of guidelines for responsible vulnerability disclosure is available at http://www.wiretrip.net/rfp/policy.html.

Security Researcher and/or Enthusiast

For an independent bughunter, there are currently no laws governing the disclosure of security issues. The disclosure debate has raged on for years ; whether it's better to keep quiet about a security issue while the vendor fixes it or announce the security bug publicly to the world at the same time (including the vendor). There are also bug bounty programs (http://www.zerodayinitiative.com and http://www.idefense.com) that will pay money for a juicy discovery in a widely used product.

For most of the bugs we've found in the course of our testing, we have leaned toward following the responsible disclosure policy outlined at http://www.wiretrip.net/rfp/policy.html.

Countermeasurs Fuzzing Countermeasures

As the customer of a VoIP product, there are a few things you can do:

• Test the software yourself for your own piece of mind.

• Ask the vendor to provide documentation of their security testing and QA processes.

• Use an inline network device such as an Intrusion Prevention System (IPS) or a Session Border Controller (SBC) to enforce some protocol conformance. This won't always work as many vendors will design their products to "enhance" the original protocol RFC with extensions to add additional features. Many IPSs and SBCs can detect many types of buffer overflows, format string flaws, and other vulnerabilities without affecting "normal" traffic.