Hacker News Reader

Comment by rixrax | Hacker News Reader

Have you thought of integrating some form of exploitability analysis[0][1] for the crashes|etc. fuzzing locates?

So let's say I upload some FOSS project and end-up finding some crashes|potential vulnerabilities. Have you considered some sort of tie-in|integration to bug bounty programs so that I could get a small pay-out without having to go through the trouble of figuring out how exploitable a given crash might be, and more importantly to actually have to deal with trying to get the attention of the project?

[0] https://www.microsoft.com/security/blog/2013/06/13/exploitab... [1] https://github.com/jfoote/exploitable

View on HN

Yep, we're definitely going to integrate more automated analysis. As of now we do some rudimentary analysis based off the type of the bug (Heap buffer overflow, UAF), read/write size, and similar metrics, but we'll be adding more advanced methods of categorization as the platform matures.

We've been thinking about the best way to use Fuzzbuzz to benefit the OSS/bug hunting community, and the integration idea is a great one. We're also providing free plans with extra CPU power for security researchers & bounty hunters.

Nice. I'm sure you've looked into various backends to use (in addition to AFL). Just wanted to give a shoutout to radamsa[0]. My [somewhat not-up-to-date] experience has been that it produced sometimes findings that AFL didn't (because of e.g. different approach relative to infinite input space).

[0] https://gitlab.com/akihe/radamsa

In regard to CPUs - my laptop reports 4 CPUs, my workstation 16 - where the value for someone involved in fuzzizng would come in my mind would be if you could take away the hassle of scaling fuzzing 'transparently' to 100 or 1000 CPUs. What I am suggesting here is that on your pricing page you might be off by factor of 100 in regard to what number of CPUs actually make offering compelling to someone who would consider outsourcing their fuzzing infrastructure.

Radamsa is awesome! Definitely agree, and one of the goals for Fuzzbuzz is to be able to hot-swap between fuzzing backends without any interface changes (or to use all backends at the same time, to account for differences in findings).

re: pricing, we do offer infinite scalability in terms of CPUs, but that might not be as clear as we'd like it from our pricing page. Or maybe I'm misunderstanding you. Either way, if you have any more thoughts/suggestions on pricing I'd love to hear it.

Reply on news.ycombinator.com