Black Hat Iron Chef Event Proclaims Fuzzing First
by Kowsik Guruswamy on 19 August 2008 - 04:36:57 PM
The recent Iron Chef event at Black Hat was a +1
for fuzzing where it was more effective than static code analysis (SCA)
according to Dark
Reading. It's also very interesting to me (and others) that both
approaches found different bugs, but fuzzing found the important one
(obviously) to do with interaction of the application with the rest of the
environment. With Gary's recent article on
informIT about the overall security
testing market expanding, it's pretty clear organizations are incorporating
different forms of testing, beyond functional and load, to improve the
reliability of the products that they are building and deploying. The history of fuzzing shows it
as a very effective mechanism to expose security vulnerabilities. Of course, there are fuzzers and then there are Fuzzers. Some are quick one-shot,
throw-aways just to get an advisory out while others shoot for aggressive code-coverage
comprehensiveness for both short-term and long-term regression. Both are incredibly effective and the
toolset/solution needs to allow the user to accomplish both.
SCA and fuzzing are complementary in nature.
They represent the classic Zen split between holism and reductionism, West and Eastern
thoughts. They are just different views
into the system with SCA focusing heavily on the structural aspects of the code
and common programming mistakes and unable to ever "understand" what
the code accomplishes in production.
SCA presents an analogy of looking at the gene
sequences in a rose to figure out how it smells. While it can identify
sequences that makes the rose susceptible to certain virii, it's impossible to
jump a level and understand what that sequence is for and how it manifests
itself into the smell.
A big advantage of fuzzing over SCA is fuzzing's
availability to anyone and everyone, especially network
operators who purchase black-box
products where the system is purely defined by how it interacts with the rest
of the environment. This allows network
operators and their vendor
suppliers to apply metrics to product quality
before, during and even post deployment WITHOUT necessarily having the source
code.
When users view fuzzing as primarily an intelligent, automated
service-level traffic generator, they suddenly open up testing options for brand new
NGN IP application worlds closely linked to
reliability and downtime and not just security. As Mu’s
product expands in capability, our customers are looking to
model system and application interactions and see how to characterize the
runtime behavior of systems in many different ways. This means Mu will allow users to spot
slow-paths in code that leads to degradation of a service by being part of the
service itself. We've seen network
operator customer deployment scenarios where Mu
analyzer knocked-down a core router for over a second with a single packet. Nothing crashed, yet there it was, the
emergent behavior that's critical to the service being up which may or may not
have to do with a specific line of code that caused the problem. As Bruce
Schneier puts it, "machines break down, systems have bugs".
At Mu, our customers firmly believe that fuzzing
is a very important aspect of their SDLC as well as the overall product
deployment life cycle. And, these
customers clearly realize fuzzing is far from a single-purpose engine to
uncover security vulnerabilities. A very
big aspect of fuzzing has always been the expert operator requirement to
interpret the results. Mu spends a large chunk of product
development in making both the operation and result interpretation processes
incredibly easier and automated for the end user. Another big observation from our customers early
on in the product design centered on building our product engine purely for the
sake of fuzzing - it didn't scale beyond the first few protocols. So instead operators and vendors had us focus on
getting the positive interactions working and even the variation generation is
internally very heavily automated and leveraged across different domains –
VoIP, Routing, Real Time Media, and Storage etc.
The overall objective our 100+ customer
deployments want, of course, is to interoperate in an extensible way with the widest
range of applications and systems as possible.
This extensibility allows us to apply the same fuzzing engine in a
very target-specific way avoiding the limitations of SCA in a vendor-specific,
source code required, least-common-denominator fashion.
Comments:
Write a comment
- Required fields are marked with *.
|
