Afl.rs: Fuzzing Rust code with american-fuzzy-lop
1–10 of 110 posts
Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop
#2Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop
#3Nice! It’s already proven to be useful: https://github.com/frewsxcv/afl.rs#trophy-case
Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop
#4Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop
#5Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop
#6 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 you build afl.rs.
I was under the impression that Afl can test any application that takes stdin. I'm underinformed for sure, so what's the idea behind explicitly adding code to support Afl fuzzing?Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop
#71. Compile-time errors. This includes most memory-related errors, which are mostly caught by the borrow checker. These are very serious errors, often with ugly security consequences. Rust's big selling point is that it can catch many different kinds of errors at compile time—but not all.
2. Run-time panics. This includes "index out of bound" errors, integer overflow errors (in debug builds only), and assertions inserted by the programmer. This is Rust's second line of defense, so to speak.
3. Expected run-time errors. These are mostly reported using return values of type Error, which is the normal way to handle errors in Rust.
Most of the errors caught by AFL seem to be errors in group (2) that ought to be in group (3). In most cases, these errors couldn't be moved into group (1), because they're not the kind of thing that's easily caught at compile-time.
So this is a really cool tool for Rust developers, especially ones working on libraries that parse untrusted input. I was especially impressed by the fact that AFL could discover overflow errors, which Rust normally only protects against in Debug mode.
Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop
#8Any 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…
afl is fundamentally instrumentation-based and likes a good look at what sorts of different branches a program is taking, it's a little bit more hands-on than just feeding things to STDIN.
Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop
#9Nice! It’s already proven to be useful: https://github.com/frewsxcv/afl.rs#trophy-case
Re: Afl.rs: Fuzzing Rust code with american-fuzzy-lop
#10Any 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…
This might be working with libfuzzer, one of the tools afl lists on its homepage as derivatives/offshoots: http://llvm.org/docs/LibFuzzer.html afl is fundamentally instrumentation-based and likes a good look at what sorts of different branches a program is taking, it's a little bit more hands-on than just feeding things to STDIN.