1/ IntroIs fuzzing obsolete? I've read an interesting presentation given at NosuchCon about analyzing execution of binaries.
One slide was saying that fuzzing is over:
So, let's try it with afl, or american fuzzy lop. As everybody knows, american fuzzy lop is a rabbit, but few knows that it's a really powerful fuzzer made by lcamtuf.
Afl can instrumentate the code in order to follow some path, instead of relying on chance only.
2/ Dumb mode, before aflIf I rely with chance only, with an initial buffer "good", and with 1000 try/seconds, I will have to wait (2^32/1000/3600/24) = 49 days to trigger a crash. That's not really efficient.
3/ AFL powerful execution modeIn order to use afl, you have to recompile your binaries with afl-gcc (wrapper around gcc). It's easy: download afl, compile it, then add in your path the build directories like:
(protip: your PATH should be set before afl, i.e. PATH=afl-dir/:$PATH won't work)
Now the code is instrumented, we just have to launch afl-fuzz:
And in less than an hour (!!!) afl trigger the crash:
That's incredible. Dumb fuzz was expecting 49 days.
4/ conclusionSo, I think that we can say that fuzzing is not over yet :-) Let's start afl everywhere in every progs!
I've currently trigger a crash in a common unix utility, but it's not exploitable (working on it, but it's hard, I can write some 0 in a not really arbitrary location :-( ).
What I miss so much is the same fuzzer for networking utility. Kind of :
printf 'GET / HTTP/1.1\r\nHost: localhost\r\n\r\n' > tescases/request
afl-fuzz -i testcases/ -o findings httpd @@