Hacker News Reader

Comment by 0x0 | Hacker News Reader

I've been following posts about this tool for a few weeks and it is really remarkable how many interesting results are already popping out already. In particular since static analyzers have been around for years and years.

I'm assuming afl-fuzz is particularly CPU-bound, and it would be interesting to see some numbers about how many CPU years are being dedicated to it at the moment - and if we would see even more interesting stuff if a larger compute cluster was made available.

It's also super scary how "effortlessly" these bugs appear to be uncovered, even in "well-aged" software like "strings".

View on HN

It would be pretty cool to have a public cluster that anyone can submit jobs to that are prioritized based on amount of donated CPU cycles. Instead of "Seti at home" it would be "fuzz at home".

I don't think that would be that efficient of a use of computing resources. Each instance explores the same instruction space. It keeps track of where it's explored, and uses various techniques to explore different parts of space.

It's very likely that multiple instances, if run in parallel and with no data sharing, will explore a lot of the same space.

Also, making a public cluster would be a security challenge. It runs arbitrary C/C++ code, and can trigger code paths that the developers didn't even realize. How would your box stand up to multiple grabs of 4GB of memory?

Don't have instances explore the same programs starting from the same state. Have state reported back in intervals so other workers can be scheduled to resume the work if that one goes down.

Security would be an issue. A VM would probably be a hard requirement. That can bound the memory usage, hardware calls, etc.

Even starting from different states doesn't help, because afl uses semi-random search techniques. It's very likely that different start locations will still have a large overlap.

Nor is it obvious that state reporting is useful. I ran afl for about 4 days. It ran my test code about 1,000 times per second, for a total of nearly 1/2 billion test cases.

That's a lot of data exchange for each program to report and resynchronize.

I'm not saying it's impossible. I'm suggesting that it's likely not worthwhile. It would be better to support multiprocessing first, before looking towards distributed computing.

As I understand it, it works by exploring different codepaths. So you just assign each computer to work on one seed file or codepath. Each as different as possible covering the largest area possible. After awhile then decide what paths are the most interesting to explore and reassign.

afl-fuzz can be parallelized fairly easily. The exchanged data amounts to newly-discovered, interesting inputs that then seed the subsequent fuzzing work.

Great work with afl. I tried it out last week, and found two segfaults and a stack smash detection in one program. I tried it on another program, only to have gcc crash with an internal error. :(

By parallelized, do you mean on the same machine or across a distributed cluster? If they only share the same set of interesting inputs, won't the different nodes also end up searching much of the same space? .... Hmm, no I see how I could be wrong. With interesting seeds, boring space is easy to re-identify, so there's a trivial amount of duplicate work, and the rest is spent just trying to find something new and interesting.

Reply on news.ycombinator.com