Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Afl.rs: Fuzzing Rust code with american-fuzzy-lop

github.com

Post reply on HN
Print view View original

11–20 of 110 posts

Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop

#11

Post by zuzun »

cm3 wrote: post #6

Any idea as to why the following requirement? This will limit Afl.rs users quite a bit. afl.rs needs to compile against a version of LLVM that matches rustc's. The easy solution (if you can wait on a slow build) is to build rustc from source and put it in your PATH. Then afl.rs's build script will find llvm-config automatically. Otherwise, the environment variable LLVM_CONFIG should hold the path to llvm-config when…

I think it injects code at branches to observe the branch coverage. After all you have to compile your C programs with the afl-gcc binary. Maybe you could ptrace every single instruction executed by the program and then stop at every jump and use the relative values of the IP to identify branches... I don't know if that would work, but it would be much slower.

Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop

#12

Post by masklinn »

zamalek wrote: post #3
cpach wrote: post #2

Nice! It’s already proven to be useful: https://github.com/frewsxcv/afl.rs#trophy-case

Someone on the brotli team is absolutely smitten with the tool.

It seems to be more that the afl-rs dev used brotli-rs as testing grounds.

Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop

#13

Post by masklinn »

cm3 wrote: post #6

Any idea as to why the following requirement? This will limit Afl.rs users quite a bit. afl.rs needs to compile against a version of LLVM that matches rustc's. The easy solution (if you can wait on a slow build) is to build rustc from source and put it in your PATH. Then afl.rs's build script will find llvm-config automatically. Otherwise, the environment variable LLVM_CONFIG should hold the path to llvm-config when…

Data input goes through stdin, but AFL needs to instrument the binary to observe branch coverage and changes in branch coverage across varying inputs.

From the alf-fuzz site:

> American fuzzy lop is a security-oriented fuzzer that employs a novel type of compile-time instrumentation and genetic algorithms to automatically discover clean, interesting test cases that trigger new internal states in the targeted binary.

That's why you need to compile C programs with afl-gcc and C++ programs with afl-g++: http://lcamtuf.coredump.cx/afl/QuickStartGuide.txt

Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop

#15

Post by frewsxcv »

cm3 wrote: post #6

Any idea as to why the following requirement? This will limit Afl.rs users quite a bit. afl.rs needs to compile against a version of LLVM that matches rustc's. The easy solution (if you can wait on a slow build) is to build rustc from source and put it in your PATH. Then afl.rs's build script will find llvm-config automatically. Otherwise, the environment variable LLVM_CONFIG should hold the path to llvm-config when…

Author here.

AFL is coverage-guided fuzz testing (fuzz testing that relies on code coverage).

Someone (not me) wrote an "LLVM pass" that loops through the generated LLVM IR for any LLVM-compiled program and injects the necessary AFL instrumentation such that AFL can work on it:

https://github.com/mirrorer/afl/blob/master/llvm_mode/afl-ll...

Since Rust uses LLVM when compiling a binary, all afl.rs does is incorporate this instrumentation and AFL just needs to be run on the resulting binary.

There are multiple versions of LLVM though. Rust is compiled using a specific version of LLVM. Since the LLVM pass above is reading the generated LLVM that Rust produces, the versions can't be too far off otherwise the LLVM pass might see some unrecognized symbols.

The README in the project suggests just compiling Rust which also compiles LLVM, then you'll have a version of LLVM that is guaranteed to be the same when you setup the instrumentation.

I think it might be sufficient to update the documentation to suggest the user of afl.rs just download and use LLVM 3.8 since this is the major version that Rust uses internally. I need to do more testing to confirm this will work for everyone, then I can update (and greatly simplify) the README.

Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop

#16

Post by frewsxcv »

masklinn wrote: post #12
zamalek wrote: post #3

Earlier quoted context omitted.

Someone on the brotli team is absolutely smitten with the tool.

It seems to be more that the afl-rs dev used brotli-rs as testing grounds.

If anything, it felt like I was practicing some sort of fuzz-driven-development for brotli-rs knocking out a bunch of corner cases.

Coincidentally though, I am fuzzing a different Brotli library testing some unpushed afl.rs changes: https://github.com/dropbox/rust-brotli-no-stdlib

Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop

#17

Post by cm3 »

frewsxcv wrote: post #15
cm3 wrote: post #6

Any idea as to why the following requirement? This will limit Afl.rs users quite a bit. afl.rs needs to compile against a version of LLVM that matches rustc's. The easy solution (if you can wait on a slow build) is to build rustc from source and put it in your PATH. Then afl.rs's build script will find llvm-config automatically. Otherwise, the environment variable LLVM_CONFIG should hold the path to llvm-config when…

Author here. AFL is coverage-guided fuzz testing (fuzz testing that relies on code coverage). Someone (not me) wrote an "LLVM pass" that loops through the generated LLVM IR for any LLVM-compiled program and injects the necessary AFL instrumentation such that AFL can work on it: https://github.com/mirrorer/afl/blob/master/llvm_mode/afl-ll... Since Rust uses LLVM when compiling a binary, all afl.rs does is incorporate…

Thanks, because the way which snapshots of LLVM and rustc are required to build a certain rustc release does not make it an easy to use solution for common Rust users. It'd be great if an existing LLVM 3.8 can be leveraged.

Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop

#18

Post by frewsxcv »

pjmlp wrote: post #14

> Nightly build of Rust Oh well....

Regarding using stable builds of Rust with afl.rs: If I could, I would.

afl.rs uses a Rust compiler plugin to register the LLVM pass needed to instrument Rust programs so that AFL can run on them:

https://github.com/frewsxcv/afl.rs/blob/master/afl-plugin/li...

Compiler plugins in Rust are currently unstable, and as far as I know, are not on a path to stability in the near-term.

https://doc.rust-lang.org/book/compiler-plugins.html

Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop

#19

Post by frewsxcv »

loktarogar wrote: post #5

I expected this to be something about Australian football, but this is pretty good too

Yes, the shared acronym makes Googling for anything AFL related rather annoying. The results are usually a mixture of Australian football, American rabbits, and fuzz testing.

Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop

#20

Post by cm3 »

masklinn wrote: post #13
cm3 wrote: post #6

Any idea as to why the following requirement? This will limit Afl.rs users quite a bit. afl.rs needs to compile against a version of LLVM that matches rustc's. The easy solution (if you can wait on a slow build) is to build rustc from source and put it in your PATH. Then afl.rs's build script will find llvm-config automatically. Otherwise, the environment variable LLVM_CONFIG should hold the path to llvm-config when…

Data input goes through stdin, but AFL needs to instrument the binary to observe branch coverage and changes in branch coverage across varying inputs. From the alf-fuzz site: > American fuzzy lop is a security-oriented fuzzer that employs a novel type of compile-time instrumentation and genetic algorithms to automatically discover clean, interesting test cases that trigger new internal states in the targeted binary.…

I see, so does that mean it potentially would be required to explicitly support other code generators (GHC, OCaml, or something else), assuming the existing instrumentation is insufficient?
Post reply on HN