Message-ID: <2b87e78b0607110825r11ec2c2eoedaa65350cc601e0@mail.gmail.com>
Date: Tue Jul 11 16:25:44 2006
From: discojonny at gmail.com (Disco Jonny)
Subject: Fuzzing Microsoft Office

hi,

On 11/07/06, Valdis.Kletnieks@...edu <Valdis.Kletnieks@...edu> wrote:
> On Tue, 11 Jul 2006 13:52:49 BST, Disco Jonny said:
>
>
> Out of curiosity, how do you determine conclusively that they're in fact
> different crashes, rather than just different symptoms of the same problem?
>

by using a controlled environment and setting appropriate weights.
But yes, it is not an easy task, but one i am quite close to
mastering.

and by mapping the file headers/format (yeah this can be done with
input validation too) - this is why i am only working with paragraphs
and bulletpoints / numbered lists at the moment. :) - smaller
applications succumb a lot quicker, maybe you could to the whole app
in one go with them...

There are a few tricks that i dont want to go into here - maybe after
i have got it nailed down then I will.

> For instance, a bounds check on string A that trashes memory - can manifest
> as almost *anything*, as it depends on what the *next* thing in memory is, and
> when/how it gets dereferenced.  This is particularly an issue when it's heap
> corruption.  If the previous sentence had 2 bold strings, then thing B on
> the heap gets splatted, causing one crash, but if there's an italic string,
> then it's C that gets trashed, causing a different manifestation.
>

Ah yes, but this is not how i test. I dont just attach a debugger and
off i go.  I actually map the process path, vars and how they are
used.  every file i launch i know what it should be doing, i then
compare this against a map of what it has already done.  (im not sure
if this is making sense - its quite hard to explain without giving it
all away ;)  using this method you can also find race conditions, heap
overflows, integer overflows, etc (i have only found a handful of bugs
where the bug ittself causes the eip to be overwritten.) the bugs i
tend to find are much more subtle.

so just to say again, I am not just checking for exceptions.  I see
every file run as more information that i can get, and i grab it all.
(the only diff between white box and black box is information.)

the main trouble is not if the next sentience contains "A quick brown
fox" then next time it contains "But the fox was quick" - thats just a
retarded way to test.  the issue is when the last program loaded was
firefox, then this word file.  - i have no elegant solution for
this... yet... i got some good ideas, but we shall see.

> It's still the same bug with A though.

yeah, and it is a lot more obvious a lot earlier on (if you map a
program, rather than just look for exceptions).  just cause 2 bugs
have an exception on the same instruction with the same value does not
mean that they are the same.
(one could get its null from DS:EAX + 8 (which == 00000000) then go
into a function with eax as 00000000, where as another might wipe out
EAX with something else, then go into the same function.  - two
different bugs, with exactly the same results.

this works in reverse too.

i hope this helps a little... erm, i guess i could try to explain it
better if you want?

cheers,

dj.

Powered by blists - more mailing lists