Hello everyone, as I mentioned during yesterdays call when we discussed fuzz testing, I have made very positive experience with using AFL. [1] In contrast to more basic fuzzers, afl uses instrumentation on the code that is added at compile time. The instrumentation is used to more efficiently generate fuzz input that causes the use of new branches in the code. An example to that effect is that when fuzzing libjpeg and using an 'a' point for fuzzing, afl will quickly come up with various broken and valid jpeg files, something most simple fuzzers wouldn't. Also, afl can generate a minimized corpus of input files from the fuzzing process that still has the maximum branch coverage achieved during fuzzing, which is useful to test for regressions without running the complete fuzzing process again. I wrote a small tool called wuschl which wraps around afl and collects the minimized corpus to use it for regression testing. [2] To make use of wuschl one needs to install afl and wuschl and write one test function that passes its input to the function to be fuzzed. Having that, one can run fuzzing and then collect the minimal corpus. After that, regression tests based on the corpus can be run without any need for wuschl or afl. Just wanted to point out the existance of AFL and also wuschl since I think that they might be useful to implement fuzzing for FRR and get the test coverage up. -Christian [1] http://lcamtuf.coredump.cx/afl/ [2] https://github.com/cfra/wuschl
Could we also take a look at google oss fuzz project : https://github.com/google/oss-fuzz I've created an issue where we can talk about it: https://github.com/FRRouting/frr/issues/479 Best regards Rémy 2017-05-11 0:08 GMT+02:00 Christian Franke <chris@opensourcerouting.org>:
Hello everyone,
as I mentioned during yesterdays call when we discussed fuzz testing, I have made very positive experience with using AFL. [1]
In contrast to more basic fuzzers, afl uses instrumentation on the code that is added at compile time. The instrumentation is used to more efficiently generate fuzz input that causes the use of new branches in the code. An example to that effect is that when fuzzing libjpeg and using an 'a' point for fuzzing, afl will quickly come up with various broken and valid jpeg files, something most simple fuzzers wouldn't.
Also, afl can generate a minimized corpus of input files from the fuzzing process that still has the maximum branch coverage achieved during fuzzing, which is useful to test for regressions without running the complete fuzzing process again.
I wrote a small tool called wuschl which wraps around afl and collects the minimized corpus to use it for regression testing. [2]
To make use of wuschl one needs to install afl and wuschl and write one test function that passes its input to the function to be fuzzed.
Having that, one can run fuzzing and then collect the minimal corpus.
After that, regression tests based on the corpus can be run without any need for wuschl or afl.
Just wanted to point out the existance of AFL and also wuschl since I think that they might be useful to implement fuzzing for FRR and get the test coverage up.
-Christian
[1] http://lcamtuf.coredump.cx/afl/ [2] https://github.com/cfra/wuschl
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
To anyone interested, I put the notes i took on fuzzing bgpd here: https://gist.github.com/qlyoung/f374581b8051e0fe81b416b7d95c680b Did this on a ~december 2016 version of frr so some stuff may have changed. On Thu, May 11, 2017 at 3:50 AM, Remy Leone <remy.leone@inria.fr> wrote:
Could we also take a look at google oss fuzz project : https://github.com/google/oss-fuzz
I've created an issue where we can talk about it: https://github.com/FRRouting/frr/issues/479
Best regards
Rémy
2017-05-11 0:08 GMT+02:00 Christian Franke <chris@opensourcerouting.org>:
Hello everyone,
as I mentioned during yesterdays call when we discussed fuzz testing, I have made very positive experience with using AFL. [1]
In contrast to more basic fuzzers, afl uses instrumentation on the code that is added at compile time. The instrumentation is used to more efficiently generate fuzz input that causes the use of new branches in the code. An example to that effect is that when fuzzing libjpeg and using an 'a' point for fuzzing, afl will quickly come up with various broken and valid jpeg files, something most simple fuzzers wouldn't.
Also, afl can generate a minimized corpus of input files from the fuzzing process that still has the maximum branch coverage achieved during fuzzing, which is useful to test for regressions without running the complete fuzzing process again.
I wrote a small tool called wuschl which wraps around afl and collects the minimized corpus to use it for regression testing. [2]
To make use of wuschl one needs to install afl and wuschl and write one test function that passes its input to the function to be fuzzed.
Having that, one can run fuzzing and then collect the minimal corpus.
After that, regression tests based on the corpus can be run without any need for wuschl or afl.
Just wanted to point out the existance of AFL and also wuschl since I think that they might be useful to implement fuzzing for FRR and get the test coverage up.
-Christian
[1] http://lcamtuf.coredump.cx/afl/ [2] https://github.com/cfra/wuschl
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
participants (3)
-
Christian Franke -
Quentin Young -
Remy Leone