Monday 11th May 2015: 6.06pm. Link shared: http://llvm.org/docs/LibFuzzer.html
As part of publicising my C++ Now 2015 talk next week, here is part 7 of 20 from its accompanying Handbook of Examples of Best Practice for C++ 11/14 (Boost) libraries:
7. SAFETY: Strongly consider a nightly or weekly input fuzz automated test if your library is able to accept untrusted input
If your library can consume any form of serialisation or parameters supplied from a network or file or query, including any regular expressions or any type of string even if you don't process it yourself and hand it off to another library, then you need to be doing input fuzz testing for a few hours weekly. Even with ubsan enabled in release builds (see previous section) and therefore use of untrusted input to subvert your security is harder, one can use missing code path verification logic to cause programs to delete or replace user data or write into secure data without introducing undefined behaviour.
The classic tool for fuzz testing data inputs is American Fuzzy Lop (afl). This is a mature, very well understood tool. You should use it in combination with the runtime sanitisers described above, so ideally with valgrind + ubsan, but if valgrind is too slow then with the address sanitiser + ubsan. You may also wish to consider additionally fuzz testing the parameters of every API in your library, see below for tooling to help with that.
One of the most promising new input fuzz testing tools going into the long term is LLVM's fuzz testing facilities which are summarised at http://llvm.org/docs/LibFuzzer.html as they make use of the clang sanitiser coverage recording facility to additionally find the code paths least covered, plus the tool is very fast compared to afl.
http://cppnow2015.sched.org/event/37beb4ec955c082f70729e4f6d1a1a05#.VUuMqvkUUuU
#cpp #cplusplus #cppnow #cppnow2015 #c ++ #boostcpp #c ++11 #c ++14