Live data from Hacker News

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

github.com

1–10 of 110 posts

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

#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 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

#7
Randomly looking at the "Trophy Case", it looks like most of these errors are run-time "panics". We can break Rust errors down into three main categories:

1. 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

#8
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…

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.

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

#10
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…

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.

No, afl.rs is not using libFuzzer. afl.rs is using llvm_mode code in afl.
Post reply on HN