Fuzzing with AFL is an Art

moyix.blogspot.com

109 points·moyix··7 comments

Great to read real-world use cases.

Tangent-ish question, I've seen some work on AFL for Rust[1], how much of this understanding maps to Rust? Is the instrumentation path pretty uniform for LLVM based binaries?

[1] https://github.com/frewsxcv/afl.rs

I wonder if fuzzing with libFuzzer is less of an art? http://llvm.org/docs/LibFuzzer.html

Alex, an SDE from AWS S3, recently added LibFuzzer fuzzing to s2n: https://github.com/awslabs/s2n/pull/263 . The integration has been very simple, very impressive, and it has already found an issue we hadn't triggered with afl (a small memory leak in an error case). The minimization step is a big help in improving the branch coverage.

LibFuzzer runs in the same process as the code you want to test, right? Doesn't that mean you have to take special care to recover from errors? I mean, if it messes up the heap, for example, it would be possible but tricky to continue running. And continue is what you want, because then you save a process restart when exploring the parameter space (which makes it very fast).

Hi! Take a look at libFuzzerfication project at https://github.com/ouspg/libfuzzerfication

LibFuzzerfication project uses libFuzzer for fuzzing popular applications and libraries.

There are already some test stubs and mysamplelib stub is very good for learning purposes.

I've been fuzzing a target pretty judiciously, and I have seen all of these effects. Glad to see somebody do a writeup. The dictionary is a huge boon, especially for text-based files.

Shameless plug: I created a project that simplifies building jumping straight into fuzzing of most command-line Debian projects. Have a look here:

https://github.com/d33tah/aflize

Reply on news.ycombinator.com