[fuzzing] Hey all

[nnp]

On Mon, Mar 17, 2008 at 10:17 AM, Andre Gironda <andre at operations.net>
wrote:

> On Sun, Mar 16, 2008 at 10:16 AM, Jared DeMott <demottja at msu.edu> wrote:
> > Sounds like the jury of security pros has spoken: No Fuzzing Cert.
>
> --snip--
> Part of the problem I've seen with fuzz testing is that everyone seems
> to be focused on the almighty 0xC0000005 (i.e. Windows memory access
> violation).  Everyone wants to overwrite EIP.  Testers typically don't
> consider fault-injection, they don't consider platforms outside of
> Windows, and they don't consider anything besides stack-based buffer
> overflows.
>

I don't think that is true. There are a number of top class fuzzing tools
for Linux also (that both run on Linux and can target Linux based
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.


> Does vulnerability research include exploit writing?  There is a lot
> to talk about here, and I doubt with the many voices I hear on this
> thread - that we'll come to any answers or solutions.  So let's get
> our conversations about our disagreements (or agreements) more in the
> open and let's work with someone who has actual knowledge about how to
> product long-term statistics/comparatives (i.e. not me).
>

I think it depends on your job. As a quality tester that is part of the
software development process then probably not. It should be sufficient to
produce a string or set of strings that will crash the application, hand it
off to the development team and expect them to patch the issue. 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.

-nnp
-- 
http://www.smashthestack.org
http://www.unprotectedhex.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.whitestar.linuxbox.org/pipermail/fuzzing/attachments/20080317/288e63ab/attachment.htm