[fuzzing] Hey all

[Andre Gironda]

On Mon, Mar 17, 2008 at 5:14 AM, nnp <version5 at gmail.com> wrote:
nnp,

Thanks for focusing on the two issues from my email that I care the
least about, but were most important for you to answer to appear
intelligent compared to the rest of the group.  Care to comment on any
of the rest of my original post?

> applications). Autodafe, GPF, Flayer, Bunny the Fuzzer etc. All these tools
> are far more advanced than what is publicly available to do the same on
> Windows. As for not targetting anything besides stack-based buffer
> overflows, I think if you look at the fuzz strings people were using as far
> back as SPIKE you can see strings for integer issues, unicode issues, format
> string vulnerabilities, directory traversal, command execution and SQL
> injection.

I'm familiar with all of these.  That doesn't change my point.  My
point was that most testers are too specialized and obsessed with
classic vulnerabilities/exploits on Windows.

To further my point even more, all of the vulnerabilities/tools you
named are still quite classic (and/or outdated).  What about
heap-based attacks, attacks on pipes, problems with signals, issues
with time & state, as well as many of the other less-popular (or
should I say less understood?) software weaknesses?  I admit that
traversals are interesting, but everything at the access level is
relatively classic and played out.  Most are just flatly "input
validation" problems that can be tested for with unit testing.

> > Does vulnerability research include exploit writing?
>
> I think it depends on your job. ... If you work
> for a company that does security assessments or vulnerability research then
> sometimes it can be difficult to convince the client that the issue you are
> reporting is a) exploitable in the real world or b) a serious issue. In this
> case an exploit can often get your point across easier than an argument.

I read in a book on "Secure Programming" once that this is the
"Exploitability trap" and not to fall into it.  I say go for the easy
argument.  Code is either obviously secure, ambiguous, or obviously
insecure.  If the code is obviously insecure or ambiguous - it must be
made "obviously secure".  Client still doesn't understand?  Ask the
client if they would like for you to outsource the writing of the
exploit to a bunch of Chinese programmers you met on an underground
forum or irc channel.  I hear crowdsourcing is popular these days.

Back to the original topic, I think that any new certifications will
hurt us more than help.  I think this because "security professionals
/ vulnerability researchers" are already a bunch of white males with
5-20 of information security experience and close to zero experience
outside of our own industry.  Can we pigeon-hole ourselves and be
over-specialized any more than we already are?  Would this be a good
thing?

Cheers,
Andre