Potential for Good: ‘Month of X Bugs”™ Projects

Another ‘Month of’ bugs is coming in June it seems”¦ This time around it appears that search engine bugs have become the item du mois to target by researchers. The announcement comes even before the Month of ActiveX bugs has finished.

There have been browser bugs (MoBB), kernel bugs (MoKB), Apple bugs (MoAB), PHP bugs (MoPB), and MySpace Bugs (MoMBY). We are currently having a month of ActiveX bugs (MoAXB). There was even been a parody on April Fool’s Day about the ‘Week of Vista Bugs’.

Although in their infancy, these projects have been trending steadily towards what appears to be a monthly ‘month-of bugs’ cycle.

Month of Browser Bugs (July 2006)
Month of Kernel bugs (November 2006)
Month of Apple Bugs (January 2007)
Month of PHP bugs (March 2007)
Month of MySpace Bugs (April 2007)
Month of ActiveX Bugs (May 2007)
Month of Search Engine Bugs (June 2007)

I guess we have to just get used to this trend – it doesn’t appear it’s going to go away any time soon.

So do these postings actually help get things fixed quickly? Let’s take a quick peak under the hype for some previously completed months:

Now, before everyone starts throwing around the “Yeah, but what about. ”¦” comments, we should agree there is room for differing translations of these numbers. For example, the “Month of PHP Bugs” project manager reported several of these issues to the vendor prior to disclosing them publicly–thereby skewing the numbers (because they were already fixed). Also take into account that some of the issues are very low risk and may just be deemed as a “casualty of war.” Issues like a local denial-of-service flaw or a one-in-a-million-chance code-execution vulnerability were probably not high on those vendors’ list of priorities–especially if they had a reliable, remote code-execution issue that already needed attention.

Even taking into account the variables, it does appear that vendors are taking notice of this format. Whether you love ‘em or hate ‘em, it looks like the “Month-of” projects are having an impact on the vulnerability landscape (at least in their embryonic stage).

In the end, these projects are about education–of vendors, administrators, and developers.

Who can argue with that?

_____________ ADDED May 21, 2007 ______________________________________________

This post was intended to explore the impact of these projects, not the method of disclosure used. I think we all can agree that responsible disclosure is first and foremost the best way to do this – while allowing for the most protection from potential zero-day exploitation. After responsible disclosure (hence, ‘in the end’) the educational purposes reap many rewards for all of us. Vendors can learn from their mistakes, administrators can plan their defense-in-depth strategies from what has been presented, and developers can learn about bad coding practices and the ways in which their code can be broken. Put another way, it allows for a manual of what NOT to do. This is the ‘potential for good’ that I was inferring with the title.