Re: New Binary Bruteforcing Method Discovered

From: Charles 'core' Stevenson (core@bokeoa.com)
Date: 03/28/02 

Date: Thu, 28 Mar 2002 02:05:18 -0700
From: Charles 'core' Stevenson <core@bokeoa.com>
To: Liedtke Goetz <goetzliedtke@yahoo.com>

I couldn't agree more. Actually I was shocked to see the post because
I've been developing a program called superfuzz for about two months now
after Dave Aitel turned me on to his locale and getenv fuzzer which uses
  ld preload (sharefuzz which is available on the @stake site). I didn't
want to reply to this until I was certain if the post was intended to
mock my work or what. Right now I'm working on implementing a ptrace
plugin for my fuzzer. At this point it's just a nice framework for
fuzzing every binary on a Linux system. It should be portable. In any
case fuzz testing is as old as dirt. I admit that I thought by
developing such a tool up to a level where I was confident to release it
that I might gain some praise but in retrospect I'm glad this happened
first.

If anyone wants to work on superfuzz with me feel free to drop me a
line. Anyways since we're all obviously secretly creating our own
fuzzers why not just get together and create a useful tool for the
community. With that here's a URL to my previously unreleased fuzzer:

http://core.def-con.org/files/superfuzz-0.1.0.tar.gz

Keep in mind that I was just brainstorming and the code isn't really
where I wanted it to be. But I feel like releasing it now is right. So
what exactly does my SuperFuzz do? It recursively searches the file
system for set[ug]id binaries or if given the -a option all ELF binaries
which it then copies locally and performs some laughable attempts at
fuzzing. The reason it doesn't do anything spectacular is that about
half way through brainstorming/coding a friend of mine suggested that I
use ptrace instead of the ld preload method. I have never done any sort
of ptrace programming so while I am learning there does not exist such a
plugin. The dream for me was to create a tool that would allow me to
install distro after distro (everything installs) and run setup
superfuzz, then come back a few days later and find a log of all the
applications that crashed or hung with any respective core files and
other information. And in my mind I imagined that some exploitation
methods are so straightforward that superfuzz might even write exploits
for certain vulnerabilities based on a template. Equiped with this tool
I was hoping to have a massive amount of unknown vulnerabilities to
release to bugtraq. Selfish... So what needs to be done? We need to
implement ptrace() or something like it so that we can send back the
appropriate formated data in order to try and crash the program. Black
box or totally random fuzzing plugins should also be created. Although
for the security minded person a nice large buffer of A's is nice too ;)

There should be some way to prevent the fuzzer from well doing things
that are counterproductive to our goal such as trying to fuzz killall5
;) (Been there done that). Ok I'll shutup now... but again let me know
if you want to work on this. Two heads are better than one.

</RANT>

Best Regards,
Charles 'core' Stevenson

Liedtke Goetz wrote:

> and even mixter weighed in, all of which caused me much amusement.
> Oddly enough, the whole concept of "fuzz" testing was pioneered
> (although we didn't think it was important enough to tell anyone) 20+
> years ago. We called it "do a faceplant or smash your hand across the
> keyboard and see if the application crashes". Folks, this is nothing
> new or original. The shared library concept is somewhat original, but
> it may miss application layer stupidity. This type of testing has
> been
> a discussion point of computer scientists since before most of you
> were
> born - how does one test applications without testing every possible
> path? See Michael Zalewski's erudite discussion on this problem in
> another posting.
> It is fascinating to me how the testing world (which is quite old in
> Internet time, predating as it does the Internet) and the
> vulnerability
> assessment world are converging. Unfortunately, the vulnerability
> assessment world is trying to relearn every lesson and reinvent every
> wheel. Paraphrasing "Read a Book" - "Read the Research". Learn from
> what others have done before you.
>
> Goetz Liedtke
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards®
> http://movies.yahoo.com/
>
>