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 <arcsigh...@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...@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.mug...@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
>> <0xjbrow...@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.lic...@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 <0xjbrow...@gmail.com>
>>>>>>>> I consider you a loser, Pete/Julio/Loser.
>>>>>>>>
>>>>>>>> On Fri, Mar 6, 2009 at 3:03 PM, Pete Licoln
>>>>>> <pete.lic...@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 <rjcamar...@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
>>>>>> <0xjbrow...@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.lic...@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 <0xjbrow...@gmail.com>
>>>>>>>>>>>>> That is hilarious LOL!
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Mar 5, 2009 at 11:14 PM, Pete Licoln
>>>>>>>>>>>>> <pete.lic...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 11 fuzzers matchs for Jeremy Brown on this page LOL !
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/3/5 Krakow Labs <krakowl...@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/
