The Myth of Open Source Security Revisited


Dare Obasanjo

It is a common misconception amongst users of Open Source software that Open Source software is a panacea when it comes to creating secure software. Although this belief is rarely grounded in fact it has become a cliche that is used axiomatically by Open Source enthusiasts and pundits whenever discussions on security.

The purpose of this article is to expose the fallacy of this kind thinking and instead point to truer means of ensuring the quality of the security of a piece software is high.

Blind Faith: With Many Eyeballs, All Bugs Are Shallow

In his seminal writing The Cathedral and the Bazaar, Eric Raymond used the statement "Given enough eyeballs, all bugs are shallow" to describe the belief that given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Over time the meaning of the original quote has been lost and instead replaced with the dogmatic belief that Open Source is the panacea that solves the problems involving security in software development.

A Critical Perspective: Eyes That Look Do Not Always See

An article entitled The Myth of Open Source Security by John Viega, the original author of GNU Mailman, challenges the popular premise that Open Source and secure software go hand in hand. In the article John Viega acknowledges the fact that with lots of people scrutinizing a program's source code, bugs and security problems are more likely to be found. He then raises the point that the availability of source code does not automatically guarantee that the code has been reviewed by competent parties for a variety of reasons. Secondly people who are looking at the source code with the intent of modifying it are not necessarily in the state of mind the perform a comprehensive security audit of the code.

One deterrent to the mass review of certain Open Source projects is a high level of complexity in the code, which can be compounded by a lack of documentation. In such a scenario, it is unlikely that the average user of the software will be able to perform a good review of the code. Another reason that prevents good review of Open Source code is that most of the people only look at the parts of the code that they want to modify which may only be a small section of the code. This behavior leads to various "hotspots" in the code that are intensely reviewed because they are the most open to modification while many other sections of the code that are less likely to be useful during modifications are barely looked at. Finally he dwelled on the fact that a majority of software developers are ignorant of security practices beyond rudimentary knowledge of good practices (e.g. avoid strcpy, gets, and strcat functions in C or using encryption is good). Unfortunately security issues are more complex than most developers are aware of leading those with the best intentions to miss subtle security bugs or unknowingly introduce them into a system after a modification. Finally, the fact that some security bugs are unobvious unless one is completely familiar with several parts of the source tree and even then certain bugs may only occur when a particular sequuence of operations occurs is a reason to be wary of the claims that source availability guarantees the security of an application.

The article then goes on to use security flaws in GNU Mailman, the Open Source implementation of Kerberos and wu-ftpd as examples of how security bugs in Open Source software can be undiscovered for significant amounts of time even though the source code is available and supposedly has been peer reviewed by many eyeballs. The fact that Open Source software is beginning to be packaged as finished products more and more it is likely that the complacency of users of Open Source software will increase since people may begin to assume that the code has been peer reviewed by their vendor of choice and will thus fail to audit the code.

Seeing The Light

In a recent article on Newsforge, Eric Raymond lambasts Microsoft for the comments of one of its employees, Scott Culp, who suggests that the security community should show restraint in releasing information about vulnerabilities and exploits. ESR then goes on to tout the lack of compromises on Open Source systems and lists the reasons for the weakness in Microsoft's software to be due poor design and a lack of an independent peer review. What is of note is that the there is nothing specific to the Open Source model of software development that guarantees that a system will be well designed or that it will be reviewed by competent people willing to spend time to discover security flaws who have the prerequisite background to know what they are looking for.

Besides good design and peer review I would like to add verifying the software via formal proofs using rigorous Mathematical methods, strict development practices and security audits to the list of effective methods to be used when attempting to build a secure software system. None of the methodologies suggested is innate to the Open Source or proprietary development model although a system that uses a Bazaar model in combination with either model should fare best.

In conclusion, I'd like to share two lessons I've learned from various software engineer tomes
  1. Testing does not show the absence of bugs.

  2. Testing cannot be used to improve the quality of software but can be used to demonstrate the quality of the software.
The driving force behind Open Source software is the constant cycle of debugging and testing by its users. Unfortunately these by themselves do not improve the overall quality of a system but are merely indicators especially with regards to security. On the other hand, building security in the system via a security oriented initial design framework, security audits and development practices that eschew dangerous programming habits are surefire industry-tested methods of improving the overall quality of the security of a system.

© 2001 Dare Obasanjo