Hacker News new | ask | show | jobs
by evmunro 2668 days ago
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.
1 comments
rixrax 2668 days ago
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.

link
evmunro 2668 days ago
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.

link