- So, let's talk a little bit about fuzzing.
We talked about buffer overflows before
and you know what they were and how to exploit them.
Now, we're gonna show how to find
vulnerabilities like buffer overflows,
and one of your primary tools
in ciphering things like code inspection
where you're looking at the source code is to use fuzzing.
Fuzzing is testing that you would feed a program
unexpected data and that data could be
malformed data, it could be unexpected data,
it could be expecting an IP address
and you feed it an IPv6 address for example.
It will take action based on that input
and it will do something with it,
and sometimes you could cause the program to crash.
Fuzzing is also called negative testing.
You also hear it called robustness testing.
In other words, you're testing how robust
the program is to certain kinds of input.
This unexpected data, like I say,
it could be invalid, it could be just random data,
it could just be garbage that comes from
a random number generator that you feed to it,
and you see exactly what happens.
What will happen is, occasionally the program will fail.
It will hang sometimes, in other words,
it will get into an infinite loop and just consume 100% CPU.
In that case, what you'll do is you'll monitor the program
and if the program crashes or goes into that state,
you will see what message you sent to the program
and so in other words, you know the input
that was being sent to the program and you say,
"Look something happened, let's figure out what happened."
In other cases, you could crash,
but when you crash, it's important to know,
"Am I crashing in the same location?
"Is the input maybe different,
"but is it the same or make me crash in the same place?
"Are these crashes exploitable?"
I mean if it's a null point or a dereference
that may not be as interesting.
When I say null point or dereference
that means I'm actually reading from address zero,
which is not mapped into a process typically.
You want to know whether or not
a particular vulnerability is exploitable,
and if the program crashes and the IP is set to something
you control, then that's a great day right?
You have found a buffer overflow vulnerability
on the stack and you have direct control
of the instruction pointer.
There are different types of fuzzers.
We'll start with the dumb or mutation-based fuzzers,
and what these do is these take a known, good,
well-formed message and you somehow
change it, or massage it, so that it's
changed a little bit and maybe corrupted,
and that collection of known good messages
is called a corpus.
Let's say you're fuzzing a jpeg file,
which is an image, so you would want to have
a collection of images that exercise
different parts of the code.
You have smart or generation-based fuzzers,
and these have a data model that you have
to program ahead of time into the fuzzer
so that the fuzzer can create the message,
sometimes from scratch, and then further along,
you have evolutionary-based fuzzers and those fuzzers
actually monitor the program itself and
they glean heuristics from the program
to figure out if you're exercising
the code that you wanna exercise,
so it's constantly checking whether or not
you're actually running the code that you expect to run.