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

41–50 of 110 posts

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

#41

Post by frewsxcv »

jdright wrote: post #32
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…

Not sure about this, but isn't this something that could be integrated into rustc (or cargo at least) to be something ready to use as bench/test?

Also worth mentioning the Rust library 'quickcheck' that does something similar to what you're suggesting:

https://github.com/BurntSushi/quickcheck#the-quickcheck-attr...

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

#42

Post by pcwalton »

pjmlp wrote: post #29
Manishearth wrote: post #26

Earlier quoted context omitted.

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.

The point is that your serious enterprise customers who can't change their toolchain also can't use AFL in GCC, so blaming Rust for this makes no sense. If anyone's to blame, it's AFL for needing custom compiler instrumentation. (Though I think that's a pretty weak criticism anyway.)

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

#43

Post by Manishearth »

wyldfire wrote: post #38
pjmlp wrote: post #29

Earlier quoted context omitted.

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.

I think this is a legit complaint. I think I understand why the rust team wants folks to use nightlies for unstable features. But if you had to opt-in with special cargo/compiler flags then it would probably be sufficient.

(Such a flag exists as an environment var, but you're not supposed to use it)

I guess the idea is to dissuade people from using hacks to enable unstable features -- this will break things which depend on the library. If a library compiles on stable, it should never break due to a compiler upgrade.

(Tooling doesn't have this problem, it doesn't come into play when it's used on a dependency)

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

#44

Post by pcwalton »

pjmlp wrote: post #35
Manishearth wrote: post #34

Earlier quoted context omitted.

> Every time someone posts a cool Rust library, most of the time it makes use of nightly. Examples? Examples that aren't tools, that is. The main example I can think of is serde, and that works on stable (just works better on nightly). What's wrong with nightly for using tooling? You don't have to keep updating, you can pin to a nightly from a particular date. You can use rustup.rs to switch to stable locally if you…

Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.

In that case, you can't use AFL in GCC either!

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

#45

Post by Manishearth »

pcwalton wrote: post #42
pjmlp wrote: post #29

Earlier quoted context omitted.

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.

The point is that your serious enterprise customers who can't change their toolchain also can't use AFL in GCC, so blaming Rust for this makes no sense. If anyone's to blame, it's AFL for needing custom compiler instrumentation. (Though I think that's a pretty weak criticism anyway.)

(Technically they can use AFL in gcc, just the less powerful version --which rust stable can too, if frewscxv adds it :). I'm not sure if a more powerful version for gcc exists, like it does for clang and rust)

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

#46

Post by fulafel »

legulere wrote: post #9
cpach wrote: post #2

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

And all the bugs just caused panics, while they could have been exploitable in C.

The ASN.1 one is a different kind of crash though still sounds controlled (SIGILL).

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

#47

Post by eddyb »

ekidd wrote: post #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 co…

> These are mostly reported using return values of type Error

However, unlike more dynamic languages, the return types are usually Result, e.g. writing to a file or a socket will get you Result, values of which can be Ok(usize) (the number of bytes written) or Err(io::Error) (an I/O error which you can further inspect).

Although if you want to, you can use Result> where Error is a trait implemented by types representing some error information. You then lose the ability to inspect errors other than for reporting them wholesale, but the APIs are slightly more uniform, type-wise.

You can read about all of this and more in the dedicated chapter of the official Rust Book: https://doc.rust-lang.org/book/error-handling.html.

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

#48

Post by eddyb »

fulafel wrote: post #46
legulere wrote: post #9

Earlier quoted context omitted.

And all the bugs just caused panics, while they could have been exploitable in C.

The ASN.1 one is a different kind of crash though still sounds controlled (SIGILL).

That's LLVM's abort intrinsic - no a lot of those left around, I believe OOM, panicking while panicking and stack overflow use it or used to use it.

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

#49

Post by bluejekyll »

pjmlp wrote: post #35
Manishearth wrote: post #34

Earlier quoted context omitted.

> Every time someone posts a cool Rust library, most of the time it makes use of nightly. Examples? Examples that aren't tools, that is. The main example I can think of is serde, and that works on stable (just works better on nightly). What's wrong with nightly for using tooling? You don't have to keep updating, you can pin to a nightly from a particular date. You can use rustup.rs to switch to stable locally if you…

Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.

That sounds like a horrible work environment. Seriously, devs can't choose their favorite tools, or specifically use tools which improve their quality until IT approves it?

I've worked in bad places where it was hard to upgrade to the latest version of a language, but at least that was always under full control of the Dev group.

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

#50

Post by steveklabnik »

cm3 wrote: post #30
steveklabnik wrote: post #28

Earlier quoted context omitted.

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?

We are always interested in adding more platforms. I don't remember if there are any open issues with a MUSL host; I vaguely remember something about compiler plugins?
Post reply on HN