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

21–30 of 110 posts

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

#21

Post by steveklabnik »

cm3 wrote: post #17
frewsxcv wrote: post #15

Earlier quoted context omitted.

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.

Note that with 1.10, the way we do rustc snapshots is changing: it will build with 1.9. And then 1.11 will build with 1.10, etc. so that will help a bit.

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

#22

Post by steveklabnik »

frewsxcv wrote: post #18
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…

Depends on how you define "near term." It's being actively worked on, but is still gonna take a while.

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

#23

Post by cm3 »

steveklabnik wrote: post #21
cm3 wrote: post #17

Earlier quoted context omitted.

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.

Note that with 1.10, the way we do rustc snapshots is changing: it will build with 1.9. And then 1.11 will build with 1.10, etc. so that will help a bit.

Hallelujah. This has been a pain point for anyone who tried to build rustc on non-tier1 platforms (musl as host, etc.).

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

#24

Post by masklinn »

cm3 wrote: post #20
masklinn wrote: post #13

Earlier quoted context omitted.

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?

I think so, when using an unsupported codegen backend you'd need to add guided fuzzing support.

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

#25

Post by Manishearth »

frewsxcv wrote: post #18
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…

It doesn't need to use llvm_mode. You can do what gcc does and have an afl-gcc binary which mucks with the assembly instead of actually inserting hooks smartly. This isn't as good, but works without nightly :)

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

#26

Post by Manishearth »

pjmlp wrote: post #14

> Nightly build of Rust Oh well....

This is unfair.

AFL support for Rust is in fact better than that for gcc because Rust at least provides a plugin interface that doesn't require you to have its sources lying around -- the GCC support instruments the assembly instead of compiler IR, which is far less effective. Rust nightly at least has proper afl support, gcc doesn't.

It works for clang because llvm plugins in clang are stable, but we could get there easily -- in fact stabilizing something akin to `-Xclang` is probably something that could be done in Rust today without issue.

A stable version of afl-rs could exist that does the same thing gcc does, as I mentioned below.

As far as compiler tools are concerned, I'm mostly okay with stuff being nightly-only. These dependencies do not pollute the dependency graph and are something you only deal with locally.

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

#27

Post by frewsxcv »

Manishearth wrote: post #25
frewsxcv wrote: post #18

Earlier quoted context omitted.

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…

It doesn't need to use llvm_mode. You can do what gcc does and have an afl-gcc binary which mucks with the assembly instead of actually inserting hooks smartly. This isn't as good, but works without nightly :)

Huh, wasn't aware that's how afl-gcc worked. I'll have to look into it sometime, thanks for making me aware of it.

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

#28

Post by steveklabnik »

cm3 wrote: post #23
steveklabnik wrote: post #21

Earlier quoted context omitted.

Note that with 1.10, the way we do rustc snapshots is changing: it will build with 1.9. And then 1.11 will build with 1.10, etc. so that will help a bit.

Hallelujah. This has been a pain point for anyone who tried to build rustc on non-tier1 platforms (musl as host, etc.).

Even on those platforms, it's helpful for distros, who only want one package, not a separate bootstrapping package. I'm real glad we're doing it.

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

#29

Post by pjmlp »

Manishearth wrote: post #26
pjmlp wrote: post #14

> Nightly build of Rust Oh well....

This is unfair. AFL support for Rust is in fact better than that for gcc because Rust at least provides a plugin interface that doesn't require you to have its sources lying around -- the GCC support instruments the assembly instead of compiler IR, which is far less effective. Rust nightly at least has proper afl support, gcc doesn't. It works for clang because llvm plugins in clang are stable, but we could get there…

Every time someone posts a cool Rust library, most of the time it makes use of nightly.

How come can I advocate Rust to serious enterprise customers, if I have to justify using nightlies to make use of such tooling?

Apparently downvoting every time someone mentions the issue with nightly being required is fair.

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

#30

Post by cm3 »

steveklabnik wrote: post #28
cm3 wrote: post #23

Earlier quoted context omitted.

Hallelujah. This has been a pain point for anyone who tried to build rustc on non-tier1 platforms (musl as host, etc.).

Even on those platforms, it's helpful for distros, who only want one package, not a separate bootstrapping package. I'm real glad we're doing it.

Will we maybe also get official musl-host builds accessible via rustup and automatically fetched on such a platform?
Post reply on HN