Updated:

It has been pointed out to me that everything stated about Open Source Software in this post also applies to Free Software.

Before I start, let me make a few things clear:

I am not against bug bounties. In fact, I think they can be good for security under the right circumstances, and there is a number of people in the vulnerability coordination/bug bounty business that I have nothing but respect for (hi Casey, Katie).



I am not an Open Source “activist”, although I am a fan of the concept of Open Source.

A while back, General Motors announced that they were launching a “vulnerability disclosure program” (not a bug bounty, which some media incorrectly reported and some people assumed). Some people remarked that General Motors, a company with a yearly revenue of hundreds of billion dollars, should really be able to pay for the bugs they receive, something which was not the case. While I applaud the willingness to accept vulnerability reports rather than suing the reporter (which may still be the case according to their terms), I wholeheartedly agree with that sentiment. This also got me thinking about something else about bug hunting, or rather about the process of choosing a target to hunt in.

Generally speaking, there are only so many reasons to go looking for bugs:

Money



The lulz



Learning



Improve security



I guess for most people, it’s a combination of several reasons, but some will likely carry more weight than others. Money is for example always hard to compete with, and one could argue that fixing a critical vulnerability in a widely used product will have a bigger security impact than in one that is not widely used. This is of course something I’m aware of, so consider those scenarios as not applicable to this post.

If you are not in it first and foremost for the money, i.e. if you would consider reporting bugs to a company like GM, I’ve got a suggestion for you: hack Open Source software instead.

The pitch

Open Source Software is a lot like charity. People create software projects in their own time, and then give it away for free for the world to benefit. Some of it has a huge user base, some of it doesn’t, but overall it’s a pretty awesome thing. A lot of these projects are rarely, if ever, audited for security bugs or other weaknesses, and usually have no budget to fund it. Instead of doing free work looking for XSS in the websites of multi-billion dollar companies, something that will pretty much only benefit the companies, consider investing some time in auditing your favorite open source project. It will (potentially at least) improve the security of the project, and it will also benefit you, the auditor.

Benefit me how?

Regardless of whether it’s for a web application, a desktop application, or something else, most (but not all) vulnerability disclosure/bug bounty programs are for proprietary software. Because of this, knowledge and control of your target will most of the time be limited. This is not the case with Open Source, as you’ll have source code, server logs, etc. readily available to you. As a result, you will have the opportunity to do a much more thorough job than in a “black box” scenario, which will help in finding non-obvious bugs as well as save time in finding the obvious ones. This will give you the chance to become a better code auditor, a better sysadmin (because you’ll have to setup and configure the target yourself), and generally a better security tester.

Another great thing about auditing Open Source is that in a lot of cases, you can actually submit your own fixes for the bugs you find. This is extremely helpful as it will increase your understanding of the developer’s situation, which will benefit you greatly if your day job is finding, reporting, and making suggestions for fixing bugs.

Conclusion

While the argument made above is somewhat simplified (a critical vulnerability in a widely used commercial product, like a car, will likely have a bigger impact than one in some rarely used Open Source project) and likely contains some logical fallacies, I still believe it’s a valid one in a lot of cases. Lots of Open Source projects have just as large user bases as commercial products, but none of the budget that comes with charging for the product. Auditing these could make a big difference for the security of the projects and their users (which of course should be the end goal).

I am personally working my way through a number of Apache projects, and I am having fun (lulz are important!), learning new things, and improving the security of some projects that I use myself (expect write-ups in the future). And it feels great.