Running LibFuzzer in a Browser, via WASM [pdf] | Hacker News Reader

Running LibFuzzer in a Browser, via WASM [pdf]

github.com

Nice!

One application could be distributed fuzzing, where anyone can partake in fuzzing important software (eg. OpenSSL) by just running a web page in their browser. Native binaries are less suited for this because adequate sandboxing is hard, but the security properties offered by WASM and browsers make this no less secure than running any other web page. With this, anyone can contribute to the quality of OSS without any technical skills, anonymously and free/cheap. For vendors willing to pay bounties for (OSS) software bugs, their current process can be automated and participation is incentivized. Offering bounties (like Google does now for OSS-Fuzz integrations) for new bugs or code coverage incentivizes development of superior fuzzing/static analysis/symbolic execution tech and submission of custom-made inputs; without a centralized tracking and verification system, this would be much more tedious to organize. WebTorrent might be used for distribution of corpora/new inputs.

Right I think WASM offers some nice advantages over native for distributed fuzzing.

It's also worth pointing out that Mozilla made a (non-WASM) distributed fuzzing project, virgo: https://github.com/MozillaSecurity/virgo but it appears to be inactive.

Are there any benefits of running the fuzzer in-browser rather than on a native binary? Does the fizzier exercise different code paths for each? Do other bugs pop up?

The potential application is hinted at with the slide "OSS-Fuzz@Home". Akin to the SETI@Home* mass-distributed computing project, this has the potential to scale in a HUGE way. Anyone with a web browser could simply load the fuzzer and contribute cycles... No need for any big downloads, any installs, special software, configuration or anything! Just visit a page and you're golden.

I wonder if Google will actually build on this. It's a great idea.

[1]: https://en.wikipedia.org/wiki/SETI@home

How would this work in practice? Most if not all browsers throttle background pages.

I don't think we have plans to build this for now.

I find it a really cool idea, but for now, running fuzzers natively on Google Cloud with ClusterFuzz (https://github.com/google/clusterfuzz) suits our needs.

One challenge for the WASM approach is it will always be at least as hard to build a project for WASM as it is for native.

I haven't done a comprehensive study of this but in general I find that fuzzing programs in different environments (e.g. CPU architectures, OSes) tends to find some bugs that won't be found by fuzzing in just one environment.

But in general, I agree a lot of the bugs in WASM apps could be found by fuzzing their native versions.

Reply on news.ycombinator.com