The Uber-Fuzzer

Originally posted on on June 7, 2011

A few weeks ago I had the chance to speak at a panel at the Hack in the Box conference in Amsterdam. For those of you not familiar with the Hack in the Box organization, its a great bunch of people who volunteer their time to put together a solid conference. The panel I was on discussed the “Economics of Vulnerabilities” and it focused primarily on the various ways organizations can recognize and compensate independent security researchers. It was a very interesting discussion, and I thank Katie Moussouris from Microsoft, Steve Adegbite from Adobe, Adrian Stone from RIM, Aaron Portnoy from ZDI and Chris Evans from Google for representing.

Since Mozilla has had a bounty program since 2004 (and Netscape started its bounty back in 1995) we obviously have some rather strong opinions about what works. 🙂 Its been great seeing other software companies adopt various types of security bounty programs: Google (with great enthusiasm), Deutsche Post, Barracuda and others. The economics in our case are pretty straightforward: a researcher who submits to the Mozilla security bug bounty program gets a $3000 reward for every qualifying client bug they find, or between $500 and $3000 for each qualifying web bug. We are not buying a researcher’s silence however; we are offering a reward for constructive security research. There are no contracts or confidentiality clauses to sign. Of course, prompt payment and public attribution are also very important. 🙂

No discussion of vulnerability economics can ignore the grey elephant in the room: underground markets. Whether the color of those markets is black, grey or taupe, the fundamental objective of those buyers is to buy vulnerabilities to use as tools… implements… ok, weapons to achieve specific tactical or strategic objectives, rather than to fix those issues and protect all users. An interesting tidbit that came out during the discussion is that now researchers on those markets are being paid on an ongoing basis for as long as the vulnerability remains non-public and unfixed. This clearly is intended to minimize the odds the vendor will be able to discover and fix the issue. Something to keep in mind if you choose to go down that route.

The other thing to keep in mind with the underground markets is that they are paying for a fully reliable, weaponized exploit. In most cases this is an order of magnitude more work than simply finding a bug, and frankly something that very few researchers can actually achieve (per Aaron Portnoy of ZDI). At Mozilla we don’t need–or even want, honestly–a working exploit. We just need sufficient detail to understand and locate the bug. In most cases a simple test case demonstrating memory corruption or an assertion, or just referencing the offending lines of code is enough. Meaning a whole lot less hassle for the researcher.

This all has some rather profound implications for vendors. No longer can one expect that a zero-day will be monetized through rootkits that get sprayed across the internet, quickly alerting the vendor to the issue and allowing for a fix. Every incentive seems aligned to keep these bugs off the radar for as long as possible, meaning a quick response is no longer a sufficient primary strategy. Vendors must pursue a wide variety of means to find and fix all of those issues proactively, and not sit on bugs under the false hope that nobody else will find them. A bug bounty is a critical part of that strategy for Mozilla. It works for the same reason fuzzing works: it maximizes the potential set of inputs into the problem, greatly improving the chances of finding security bugs through unique and innovative means. Security bounty programs are the “uber-fuzzer”.

Author: Lucas Adamski

20+ years in the bay area, with a diverse experience of leading hybrid software/hardware products, security, web platforms, devops and helping drive product. Diverse background from tiny startups to large corporations, lots of experience with distributed teams and building high trust cultures (and occasionally, failing to).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.