Re: [Full-disclosure] List of Fuzzers

2009-03-13 Thread ArcSighter Elite
-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 

Re: [Full-disclosure] Exploiting buffer overflows via protected GCC

2009-02-16 Thread ArcSighter Elite
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Matthews wrote:
 I would recommend doing the following things.
 
 1. Ask on the Ubuntu GCC list what protection is implemented. (Or just look
 at the source)
 2. Use GCC to see where the execution is being redirected and so you can
 have a better visual of whats going on.
 3. Are you sure the stack is executable?
 
 
 
 On Sat, Feb 14, 2009 at 12:30 AM, Marcus Meissner meiss...@suse.de wrote:
 
 On Fri, Feb 13, 2009 at 11:50:11AM -0500, Jason Starks wrote:
 I came across a problem that I am sure many security researchers have
 seen
 before:

 ja...@uboo:~$ cat bof.c
 #include stdio.h
 #include string.h

 int main()
 {

 char buf[512];

 memset(buf, 'A', 528);

 return 0;

 }
 ja...@uboo:~$

 ja...@uboo:~$ ./bof
 *** stack smashing detected ***: ./bof terminated
 === Backtrace: =
 /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7f08548]
 ja...@uboo:~$

 I have googled my brains out for a solution, but all I have gathered is
 that
 my Ubuntu's gcc is compiled with SSP and everytime I try to overwrite the
 return address it also overwrites the canary's value, and triggers a stop
 in
 the program. I've disassembled it and anybody who can help me probably
 doesn't need me to explain much more, but I would like to know a way to
 get
 this. There seems to be some people on this list who may know something
 on
 how to exploit on *nix systems with this protection enabled.

 I do not want to just disable the protection and exploit it normally, I
 want

 Perhaps you should learn first exactly _what_ caught your buffer overflow.

 Hint: It was not SSP aka -fstack-protector.

 Ciao, Marcus

 ___
 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/

Ubuntu and recent kernels also implement ASLR. So, that may be the
issue, besides StackGuard.

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

iD4DBQFJmXGAH+KgkfcIQ8cRAmG0AJ0c9rFv2hd43oP2iR8EYCRC0gwKgwCYpXqo
1kRbO2tqcJ31JrUw3uNiRA==
=FGDQ
-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/


Re: [Full-disclosure] Exploiting buffer overflows via protected GCC

2009-02-13 Thread ArcSighter Elite
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

valdis.kletni...@vt.edu wrote:
 On Fri, 13 Feb 2009 11:50:11 EST, Jason Starks said:
 
 memset(buf, 'A', 528);
 
 Don't do that.  This sort of whoops is exactly what the gcc SSP canary is
 designed to stop.
 
 I have googled my brains out for a solution, but all I have gathered is that
 my Ubuntu's gcc is compiled with SSP and everytime I try to overwrite the
 return address it also overwrites the canary's value, and triggers a stop in
 the program. I've disassembled it and anybody who can help me probably
 doesn't need me to explain much more, but I would like to know a way to get
 this. There seems to be some people on this list who may know something on
 how to exploit on *nix systems with this protection enabled.
 
 What you want to do is be more precise in your splatting.  Instead of
 one memset, see if you can come up with a way to do *two* memsets, which
 leave your stack looking like:
 
   'A' (above the canary)
   4 unmolested bytes of canary
   'A' (below the canary)
 
 Of course, if you're trying to exploit already-existing code, you probably
 only have one memset/strcpy you can abuse, and the starting address of the
 destination is already nailed down, which means you need to fill in the
 4 bytes of canary correctly.  This means you need to find a way to obtain
 the value so you can use it.  One hint - sometimes you're better off targeting
 the stack frame 2 or 3 function calls back, rather than the *current* frame.
 
 
 
 
 
 ___
 Full-Disclosure - We believe in it.
 Charter: http://lists.grok.org.uk/full-disclosure-charter.html
 Hosted and sponsored by Secunia - http://secunia.com/

He was actually seeking for ways to bypass stack protection in gcc
environments. There may be references at the web, reducing the entropy
for prediction, brute-forcing or abusing signal handlers, could be a
good starting point. I have little experience with gcc, ask Matt Miller.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJlbfFH+KgkfcIQ8cRAtR8AKCFeamGDKgIzqjZJZLRc+WaNMdhlQCg1fc3
z3u4YNF0Hkkv+4EydOkX1oo=
=Gz91
-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/