5 ms·

AFL++ Fuzzing Framework

114 points by ducktective 6y ago

corndoge 6y ago
Having replaced afl - which google barely maintains these days - with afl++ in all of my fuzzing projects, I can heartily endorse it! Keep up the good work
- domenukk 6y ago
  Maintainer here, happy to hear that! Doing our best :) Even Google's own OSS Fuzz switched to afl++ recently (https://google.github.io/oss-fuzz/ https://google.github.io/oss-fuzz/)
- bruckie 6y ago
  Google's lack of maintenance isn't super surprising, given that Zalewski (AFL creator) left Google 3 years ago. https://twitter.com/lcamtuf/status/976307141177884672 https://twitter.com/lcamtuf/status/976307141177884672
- rwmj 6y ago
  It's a bit of a shame that AFL upstream is (somewhat) dead. I'm now mainly using honggfuzz, and maintaining both projects downstream in Fedora. It would be nice if we had only one instrumented local fuzzing framework we could all use.
  - domenukk 6y ago
    Why not have multiple with different strengths for different users, though? Honggfuzz is also really good. That being said, most distributions replace afl with afl++ these days.
simonhughes22 6y ago
It would be great if (in the repo) you could briefly explain what fuzzing in and why you'd need it. I assume it's some sort of obfuscation tool?
- Thaxll 6y ago
  Fuzzing is a technique where you send lot of random or not so random data to the input of a program to see how it reacts, does it crash, does it handle that properly ect ... For example you want to test your JSON parser, what happens if I send "{", ""\\{" etc ...
  - dwheeler 6y ago
    Fuzzers can find defects, including vulnerabilities, that might be missed by other tools. AFL used a newer technique, called being "coverage guided", that turned out to be a remarkable improvement. As a coverage guided tool it monitors how many times various code branches are taken, and if the count is different than what has seen before, the input is considered "more interesting". AFL++ inherits this capability. An impressive demo (from AFL) is that it was able to figure out the required format for a JPEG file given only one text file (which is not a JPEG file): https://web.archive.org/web/20201210022938/https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html https://web.archive.org/web/20201210022938/https://lcamtuf.b... If you're fuzzing open source software, you might consider applying to OSS-Fuzz https://github.com/google/oss-fuzz https://github.com/google/oss-fuzz which provides a lot of free compute power to run fuzzers (so that vulnerabilities can be found & fixed).
    - not2b 6y ago
      The technique has been used for at least two decades in hardware verification, though the terminology is different. If you search the literature, you'll find terms like "constrained functional verification", "coverage directed test generation", "functional coverage directed test generation", and the like. The technique is the same, random testing, with mutation to try to hit more and more coverage points.
      - pfdietz 6y ago
        It goes back af least that far in software, with the original fuzzing work from U. Wisc and McKeeman's "Differential Testing for Software". Those are blackbox techniques; AFL's advance was using a general grey box approach.
baby 6y ago
It is pretty damn fast compared to AFL, it’s also much much faster than libfuzzer. I really wish someone made a crate to use it easily in a rust project. I’m jealous of Golang built-in support for fuzzing...
- domenukk 6y ago
  There is afl-rs https://github.com/rust-fuzz/afl.rs https://github.com/rust-fuzz/afl.rs also we're working on a fuzzing library that's completely written in rust right now, stay tuned :)
  - baby 6y ago
    How do I stay tuned :D? You folks don’t have a blog
pvitz 6y ago
I am a long-term fan of The Hacker's Choice and van Hauser. I remember reading their mags, war dialing with their thc-scan (written in Pascal IIRC), downloading nasty sound files from their webserver or playing around with their CC number software. I wonder which jobs guys like Doc Holiday, Gemfire, Plasmoid or Wilkins (?) landed. There was great talent in this team.
einpoklum 6y ago
For those who were confused for a moment about what fuzzing has to do with array programming (like I was): It's AFL, not APL. AFL the "American Fuzzy Lop" fuzzer framework, by Michal “lcamtuf” Zalewski. What's a "fuzzy lop"? It's a cute kind of rabbit! : https://en.wikipedia.org/wiki/American_Fuzzy_Lop https://en.wikipedia.org/wiki/American_Fuzzy_Lop
rurban 6y ago
I recently replaced afl++ first with honggfuzz, but then llvm libfuzzer, which is superior in all aspects. Much easier to use. Finds tons of bugs in seconds, not hours. Can be externalized to be run similar to a CI instance via oss-fuzz. First I thought Radamsa was pretty cool, until libfuzzer replaced it. Best is to run all of them. For the exploding state problem with cmdline options, I usually create a special executable which randomizes all available options.

114 points by ducktective 6y ago

Having replaced afl - which google barely maintains these days - with afl++ in all of my fuzzing projects, I can heartily endorse it! Keep up the good work

domenukk 6y ago
Maintainer here, happy to hear that! Doing our best :) Even Google's own OSS Fuzz switched to afl++ recently (https://google.github.io/oss-fuzz/ https://google.github.io/oss-fuzz/)
bruckie 6y ago
Google's lack of maintenance isn't super surprising, given that Zalewski (AFL creator) left Google 3 years ago. https://twitter.com/lcamtuf/status/976307141177884672 https://twitter.com/lcamtuf/status/976307141177884672
rwmj 6y ago
It's a bit of a shame that AFL upstream is (somewhat) dead. I'm now mainly using honggfuzz, and maintaining both projects downstream in Fedora. It would be nice if we had only one instrumented local fuzzing framework we could all use.
- domenukk 6y ago
  Why not have multiple with different strengths for different users, though? Honggfuzz is also really good. That being said, most distributions replace afl with afl++ these days.

simonhughes22 6y ago

It would be great if (in the repo) you could briefly explain what fuzzing in and why you'd need it. I assume it's some sort of obfuscation tool?

Thaxll 6y ago
Fuzzing is a technique where you send lot of random or not so random data to the input of a program to see how it reacts, does it crash, does it handle that properly ect ... For example you want to test your JSON parser, what happens if I send "{", ""\\{" etc ...
- dwheeler 6y ago
  Fuzzers can find defects, including vulnerabilities, that might be missed by other tools. AFL used a newer technique, called being "coverage guided", that turned out to be a remarkable improvement. As a coverage guided tool it monitors how many times various code branches are taken, and if the count is different than what has seen before, the input is considered "more interesting". AFL++ inherits this capability. An impressive demo (from AFL) is that it was able to figure out the required format for a JPEG file given only one text file (which is not a JPEG file): https://web.archive.org/web/20201210022938/https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html https://web.archive.org/web/20201210022938/https://lcamtuf.b... If you're fuzzing open source software, you might consider applying to OSS-Fuzz https://github.com/google/oss-fuzz https://github.com/google/oss-fuzz which provides a lot of free compute power to run fuzzers (so that vulnerabilities can be found & fixed).
  - not2b 6y ago
    The technique has been used for at least two decades in hardware verification, though the terminology is different. If you search the literature, you'll find terms like "constrained functional verification", "coverage directed test generation", "functional coverage directed test generation", and the like. The technique is the same, random testing, with mutation to try to hit more and more coverage points.
    - pfdietz 6y ago
      It goes back af least that far in software, with the original fuzzing work from U. Wisc and McKeeman's "Differential Testing for Software". Those are blackbox techniques; AFL's advance was using a general grey box approach.

baby 6y ago

It is pretty damn fast compared to AFL, it’s also much much faster than libfuzzer. I really wish someone made a crate to use it easily in a rust project. I’m jealous of Golang built-in support for fuzzing...

domenukk 6y ago
There is afl-rs https://github.com/rust-fuzz/afl.rs https://github.com/rust-fuzz/afl.rs also we're working on a fuzzing library that's completely written in rust right now, stay tuned :)
- baby 6y ago
  How do I stay tuned :D? You folks don’t have a blog

pvitz 6y ago

I am a long-term fan of The Hacker's Choice and van Hauser. I remember reading their mags, war dialing with their thc-scan (written in Pascal IIRC), downloading nasty sound files from their webserver or playing around with their CC number software. I wonder which jobs guys like Doc Holiday, Gemfire, Plasmoid or Wilkins (?) landed. There was great talent in this team.

einpoklum 6y ago

For those who were confused for a moment about what fuzzing has to do with array programming (like I was): It's AFL, not APL. AFL the "American Fuzzy Lop" fuzzer framework, by Michal “lcamtuf” Zalewski. What's a "fuzzy lop"? It's a cute kind of rabbit! : https://en.wikipedia.org/wiki/American_Fuzzy_Lop https://en.wikipedia.org/wiki/American_Fuzzy_Lop

rurban 6y ago

I recently replaced afl++ first with honggfuzz, but then llvm libfuzzer, which is superior in all aspects. Much easier to use. Finds tons of bugs in seconds, not hours. Can be externalized to be run similar to a CI instance via oss-fuzz. First I thought Radamsa was pretty cool, until libfuzzer replaced it. Best is to run all of them. For the exploding state problem with cmdline options, I usually create a special executable which randomizes all available options.