The Myth of Open Source Security Revisited
by
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
- Testing does not show the absence of bugs.
- 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