[fuzzing] Fuzzing tradeoffs - where previously described?
ari.takanen at codenomicon.com
Thu Feb 1 10:49:42 CST 2007
On Thu, Feb 01, 2007 at 04:09:17PM +0000, Disco Jonny wrote:
> >Note that because the input space is always infinite,
> pardon? no it isnt. it might be huge, phenomenally huge, but physics
> stops it being infinite.
Well, actually the input space is infinite. Protocols travel in a
pipe, and there is nothing that says there is an end to them... Bits
do not run out, or take space. You might think input space is finite,
like the way Mr. Bill though we never need more than 640k of memory
(well it was not him but lets blame it on him anyways).
E.g. if a protocol specification says that:
<protocol> = <data>
<data> = 1..256 * <16bit-integer>
How many tests would we need? Fuzzing that will still have infinite
tests, provided it does not have any other limitations. Is 2^16+1 long
enough stream to inject? Is 16GB too much to try? What about if we
send even more? Where should we stop? But as you said, it might not
be sensible to go that far, but what if it will crash with one more
additional byte of data? And one more? Why set limits like Mr Bill (or
whoever) did when he did not know better?
With some protocols, you can potentially measure the maximum size of
input space. Just keep increasing the message size until the server
side will refuse any more data and close the connection (it probably
crashed in the process). But then, what if the flaw is due to a
combination of two different packets? Or three? ...
More information about the fuzzing