Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: List of Fuzzers
From: Jeremy Brown <0xjbrown41 () gmail com>
Date: Fri, 13 Mar 2009 16:22:18 -0400

Via your example:

int authenticate(char* username, char* password) {
       char* buffer[500];
       if (checkAuthentication(username, password)) {
               sprintf(buffer, "User %s succesfully logged in",
                        username);
               log("%s", buffer);
               // continue with authenticated user
               return 0;
       }

       return 1;
}

I realize that a fuzzer may not be able to trigger a bug like this. I
also think a *human* couldn't either. Because (and I'm assuming)
checkAuthentication() checks username/password against a database of
valid combinations. If that is so, then how would you practically
exploit this situation? I guess you could overflow the buffer if a
username in the database of valid credentials was over 500 bytes, but
really, I don't think this is such a good example. Understood, though,
that fuzzing has its limitations (that can be fixed and applied like
everything else) when it must fulfil certain values and/or pass
certain tests before the vulnerability is triggerable.

Jeremy

On Fri, Mar 13, 2009 at 4:39 PM, ArcSighter Elite <arcsighter () gmail com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Josh Dukes wrote:
Mr. Mustache,
As an emacs user I naturally have a very large beard, and as such am
inclined to disagree with you slightly. Though I recognize and respect
your facial hair, I do believe that the development of fuzzing
frameworks is a valid pursuit. The use of frameworks developed by
oneself, or one's security group would be a perfectly valid use.
Likewise modification and use of another person's framework I would see
as valid (and potentially fun). I would even suggest that it *might* be
valid to use someone else's fuzzing framework against one's own
applications to verify one's work, or to even generally fuzz in a
non-serious way. But I would generally agree that use of someone else's
fuzzing framework, without any modification or deep understanding of
how it work, for serious research, would be a clear misuse of fuzzing
technology in a generally script-kiddish fashion.

That said, I see "Which fuzzer on this list will help me find the most
security exploits?" as a similar statement to "Dear leet h4x0rz, plz
hlp m3 h4x0r t0nz o' stuffs. thx!"

So, Bobby, I don't wish to be rude, but please ask questions that add
more value to the conversation. That is to say, research first and ask
questions when you've exhausted your own resources. You will gain more
knowledge and irritate less people.

done.

On Fri, 6 Mar 2009 19:58:55 -0600
"Valdis' Mustache" <security.mustache+fd () gmail com> wrote:

Gabby,

As a general rule, I am opposed to fuzz. Those that are prebuscent and
/ or lack the appropriate testosterone levels to develop full and
bushy facial hair should leave matters to the professionals.

That said, I have been most impressed with the work of the markedly
hairless Mssr. Pedram Amini and his Sulley Fuzzing Framework, located
at http://www.fuzzing.org/wp-content/sulley.zip.

I believe there was a Lebanese gentleman (also notably lacking in
facial hair) from the NSA who created another popular fuzzing tool,
but I believe it was primarily only for crashing Java applications and
developing Python tutorials.


Your humble servant,
The vunts ja Valdis

On Fri, Mar 6, 2009 at 5:47 PM,  <bobby.mugabe () hush com> wrote:
Dear list,

Which fuzzer on this list will help me find the most security
exploits?

Thanks,
-bm

On Fri, 06 Mar 2009 18:37:01 -0500 Jeremy Brown
<0xjbrown41 () gmail com> wrote:
Don't act like you've gave any constructive advice to anyone in
your life.

Thanks for trolling, please don't come again.

On Fri, Mar 6, 2009 at 6:21 PM, Pete Licoln
<pete.licoln () gmail com> wrote:
Ok cool, then keep it up Jeremy.
At least you wont be able to say no one told you.

2009/3/6 Jeremy Brown <0xjbrown41 () gmail com>
I consider you a loser, Pete/Julio/Loser.

On Fri, Mar 6, 2009 at 3:03 PM, Pete Licoln
<pete.licoln () gmail com> wrote:
Well .. what i say is true.
If you cant argue on the subject then shut the hell up.


2009/3/6 Rubén Camarero <rjcamarero () gmail com>
Dont satisfy this idiot with a response, thats what he
likes..
Everybody
knows Petie is a troll on every list just use google

On Fri, Mar 6, 2009 at 10:56 AM, Jeremy Brown
<0xjbrown41 () gmail com>
wrote:
The reason anyone writes a fuzzer is to find bugs. Those
that I have
written are of course for the same purpose as the 101
listed: to find
security bugs. Your ideas are as meaningless and unhelpful
as they
have been in the past. You have no goal but to troll and
try to make
people look like fools, but you are clearly the ignorant
one.
What have you ever written? Let us see some of your code to
poke fun
of. If it is as imperfect as you then we'd have a day of
fun.
What's hilarious is that none of them are usefull :)
http://www.milw0rm.com/author/1531
http://www.milw0rm.com/author/1835

90% of the research above were found by fuzzing, and those
are public.
Clearly my fuzzers are useful.

You should really learn the protocol you want to fuzz, and
develop a
strategy before you create anything else.
Although mistakes are inevitable, and seeming how the stuff
I write
are pretty coherent to the protocol, your statements, once
again, are
unjustifiable. The strategy is simple: gather points of
input, fuzz
them, and watch for exceptions. Obviously.

Every fuzzer you've made use the SAME way to ""fuzz"" for
differents
app/protocol.
Because using a fuzzing oracle is a very good way to
identify security
bugs. Throwing random data will surely find lots of
programming
errors, but I want a shell.

The only change i see is your last fuzzer .. written in a
different
language, but still the same way ...
Yeah, I wrote it in C, and implemented a fuzzing oracle
that way. I
probably put 100 hours into it, and it gave back some nice
return. As
like the others.

So, "what ever your real name is", I will continue to write
fuzzers
and exploits. If you comments are meant to bend my attitude
or
research rather than to troll, you don't have a chance, so
get on with
your life and I will get on with mine. What a conclusion.


On Fri, Mar 6, 2009 at 10:22 AM, Pete Licoln
<pete.licoln () gmail com>
wrote:
What's hilarious is that none of them are usefull :)
You should really learn the protocol you want to fuzz,
and develop a
strategy before you create anything else.
Every fuzzer you've made use the SAME way to ""fuzz"" for
differents
app/protocol.

The only change i see is your last fuzzer .. written in a
different
language, but still the same way ...

2009/3/5 Jeremy Brown <0xjbrown41 () gmail com>
That is hilarious LOL!

On Thu, Mar 5, 2009 at 11:14 PM, Pete Licoln
<pete.licoln () gmail com>
wrote:
11 fuzzers matchs for Jeremy Brown on this page LOL !

2009/3/5 Krakow Labs <krakowlabs () gmail com>
Krakow Labs maintains a current list of security
driven fuzzing
technologies.

http://www.krakowlabs.com/lof.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-
charter.html
Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-
charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-
charter.html
Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-
charter.html
Hosted and sponsored by Secunia - http://secunia.com/


--
Rubén Camarero
CCNA, CISSP

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-
charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-
charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

- --
Be a Certified Nursing Assistant. Get local training today.
 http://tagline.hushmail.com/fc/BLSrjkqoiOCPCoMRK9ZgmTNsCtwOZXGIyrzJkWo3YmH0IyTAFJVy7s9Krni/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


I totally agree.
Generally speaking, whenever you use an automated tool to DO the work
for you, instead of HELPING you to do it, you have only 1% of success in
your task. When talking about software vulnerability research, I think
it's pretty clear that no tool could give the level of expertise
required to exploit an application. If you don't get a good
understanding on how the application works (and here I'm referring to
source code auditing and reverse engineering), if you don't know which
are the different common patterns found in vulnerable software, if you
don't know what is a security bug and what's a software bug, if you're
unable to assess whether a identified vulnerability can be proven to be
exploitable, etc, then the tool will miss you up instead of helping you,
and IMHO I think this is the case.
Security bugs come from bad cryptographic implementation, insecure
storage, to buffer overflows; even in the case you're using a smart
fuzzer which adds some knowledge (mainly protocol or file formats),
stills you could be missing some applications paths.
Please consider this simple stripped example (BTW, I don't remember much
c++ from source, but it illustrates the example):

int authenticate(char* username, char* password) {
       char* buffer[500];
       if (checkAuthentication(username, password)) {
               sprintf(buffer, "User %s succesfully logged in",                                username);
               log("%s", buffer);
               // continue with authenticated user
               return 0;
       }

       return 1;
}


This simple code path would be missed by almost any common fuzzer,
because the BO is in a code path which is conditional to successful
authentication. I think it illustrates the point.
Of course, we can -as usually done- combine it with code coverage and
memory profiling tools, which is a common approach, but still a blackbox
one.
We must see fuzzing as a way to automate tasks, not to do it for us.
We recently saw a paper about the process of identifying Adobe's embeded
 functions and then with that list, and armored with parameters
information,  giving that info to spike (which isn't an intelligent
fuzzer) to perform the remaining work, in that case, as most of them,
the "intelligence" was provided by the human, and the tool automatize it.
So, that was the long answer, the short one: no fuzzer will allow you to
identify/exploit vulns without the knowledge.


Sincerely.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJusSIH+KgkfcIQ8cRAqz3AJ9GfzLDs+H9UjwfFEzBJ6SZCdo13wCfV4va
mfA0Bb4qoFubQ9sfq2NogsA=
=Xa7h
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]