[fuzzing] unix ioctl fuzzer

[LMH]

On 1/10/07, Gadi Evron <ge at linuxbox.org> wrote:
> On Tue, 9 Jan 2007, LMH wrote:
> > I should release the AppleTalk one based on it I guess. Hope I have
> > the time later. That was a fun experience ;-)
>
> LMH, can you share some of your metholody for the MoAB fuzzing?

So far I had a tough time working around DMG, just to make sure I
didn't miss anything relevant about the format. Most of the code I've
written is Ruby (well, anyone can guess that given that every exploit
I've released since couple months ago was ruby-based), and integrated
on a private framework (using Rex from Metasploit and some home-brew
code for the modules engine, certainly simple stuff).

Normally I start by reading the specification or format description if
available. If it's not public, then I go for the source code. If that
last resource isn't there, then I usually search for existing
third-party code, documentation, etc. Actually, Hex Fiend happens to
be extremely useful for altering the data manually (check it out at
http://ridiculousfish.com/hexfiend). I miss some features, though.

When I'm done with manual work, I go ahead with coding something else
(Ruby is my choice, although the mach-o related stuff was all coded in
C, as there was existing support code, headers including data
structure definitions, etc). Fuzzing becomes useless when it just adds
more work load (unless you aim to do something else, it all depends on
your expectations and goals...). In the MoAB we are focusing on
delivering working exploits for every published issue, and that means
working with both PowerPC and x86 versions of OS X, dealing with each
different application, techniques, etc. It's a tedious task, and we
generally want to get over exploitation as soon as possible.

There's a load of stuff in OS X to play with,  network-wise. I'll be
releasing code in February probably.

Although, it's true that there's nothing like auditing the source code
when it's available. Sometimes it's creepy enough (that feeling when
you've spent a few hours non-stop, poking poorly written code around)
that you decide to code a targeted tool to test whatever protocol is
involved and go straight forward to the exploitation step, which is
where the real fun starts.

I'm not myself a fuzzing fan (really), but I hate to waste time unless
I'm being paid ;-)

Cheers.
PS: It's me getting paranoid or lately everything is being attributed
or related to fuzzing? :>
Isn't it the point behind security issues, the failure of an
application to handle unexpected conditions? Actually for the MoAB,
"fuzzing"  is certainly less involved in the process (I would be lying
if I said we aren't using similar approaches, but we are far away from
throwing dumb data at random places). I'm already sick of reading
specifications, RFCs, etc. The PDF / PostScript ones are just evil.