[HN Gopher] AFL++ Fuzzing Framework
___________________________________________________________________
AFL++ Fuzzing Framework
Author : ducktective
Score : 91 points
Date : 2021-03-12 15:04 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| simonhughes22 wrote:
| 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?
| Twirrim wrote:
| There's a good intro here: https://www.microsoft.com/en-
| us/research/blog/a-brief-introd... and afl++'s main
| documentation is here https://aflplus.plus/ which talks a bit
| about it.
|
| The goal is to find bugs in code by throwing random data at it,
| in as an intelligent fashion as possible. You can do that a few
| ways:
|
| * Give structured data to mutate a bit.
|
| * Just throw random data at it. You could do this with any
| binary that accepts data either via stdin or from a file.
|
| * Instrument the code, throw random data at it and see what
| paths of code get triggered and feed that back into the data
| generator. Drawback is you need to be able to compile all the
| code involved, so it gets fully instrumented.
|
| AFL/AFL++ sits in the third camp. You compile your code using
| it, and it then uses information it gets back to figure out
| ways to trigger code paths, by applying intelligent mutations.
| It's possible to, e.g. have code that parses a PNG image file,
| start AFL++ off with no initial data, and it will fairly
| quickly start producing valid PNG images.
|
| It's a very effective approach for finding bugs. On the AFL++
| site there's a small trophy cabinet, and AFL has a larger one
| (older project) https://lcamtuf.coredump.cx/afl/.
| Thaxll wrote:
| 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 wrote:
| 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/we
| b/20201210022938/https://lcamtuf.b...
|
| If you're fuzzing open source software, you might consider
| applying to 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 wrote:
| 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 wrote:
| 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.
| not2b wrote:
| The hardware approach isn't blackbox, it explicitly uses
| the reachable state space and constraint solving to reach
| more coverage points, to do this the exact circuit
| representation is needed.
| dathinab wrote:
| > it's some sort of obfuscation tool?
|
| I didn't expect someone on HN not to know this but then there
| are not only programmers here I guess ;=)
|
| It's a tool to find bugs. To strongly oversimplify: It throws
| random inputs at a program until it crashes.
|
| So you could say it's a tool to complement a test suit.
| wcarss wrote:
| https://xkcd.com/1053/
|
| (edit: not to imply you were making fun, your answer was
| great! But in general: everyone learns things every day. Even
| every programmer has a day where they learn what fuzzing is)
| dathinab wrote:
| Your right my answer was kinda impolite, I apologize.
| nano-erud wrote:
| This term is not used much. Most know more about "random
| testing" or "monkey testing", much more common out there. I
| think fuzzing is used a lot to find security holes and I
| think it is kind of old, very used yet though, but it is not
| something that is seen everywhere by programmers outside of
| systems programming. Not all programmers work in the same
| field, so it is not uncommon for someone not to know about
| this. In my case, I associate the term fuzzing with matching,
| for example.
| kbenson wrote:
| Somewhat. I think it might mostly be that it provides a
| much greater return for those using languages where
| incorrectly handled values have a higher chance of causing
| much worse problems, like C and C++. I think if you write
| in those languages, or like me you haven't for almost 20
| years but you're just still very interested in developments
| about them because they often seem to illuminate the weird
| quirks of computing and CPUs, then fuzzing is a much more
| common thing to have heard about.
|
| Not that fuzzing isn't useful for higher level or managed
| languages, just that it's extra useful when you throw
| likely segfaults into the mix.
| smt1 wrote:
| Fuzzing is ROI efficient (especially for time invested)
| even if you don't intend to find a segfault, but just see
| how a program works or performs across different input
| states either in or out of its usual domain (and you can
| direct the fuzzing many ways derandomizing it or
| constraining the search space, or using virtualizer like
| qemu). I like to think of it as "semantics engineering"
| with spare CPU cycles.
|
| I use fuzzers with a Redex driver usually, which is
| unusually great at intelligently driving fuzzers:
| https://docs.racket-lang.org/redex/index.html
| corndoge wrote:
| 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 wrote:
| 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/)
| bruckie wrote:
| 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
| rwmj wrote:
| 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 wrote:
| 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.
| pvitz wrote:
| 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 wrote:
| 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
| baby wrote:
| 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 wrote:
| There is 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 :)
___________________________________________________________________
(page generated 2021-03-12 23:00 UTC)