Securing Open Source Software:
Advantages and Challenges
Mitch Stoltz
Head Security Engineer
Netscape Client Products Division
Open Questions
• Is Open Source software more secure?
• What are the security advantages of the
open source model?
• What are the disadvantages?
• How can those disadvantages be overcome?
The Promise of Open Source
“Given a large enough betatester and co-developer base,
almost every problem will be
characterized quickly and the
fix obvious to someone.
Or, less formally, ‘Given
enough eyeballs, all bugs are
shallow.’ I dub this: ‘Linus's
Law.’”
- Eric Raymond,
“The Cathedral and the Bazaar”
The Promise of Open Source
• No organizational bottleneck in the original
developer
– Anyone can download and test
– Less communication necessary
– Development, testing/verification, and
maintenance can be done by different
organizations
The Promise of Open Source
• Independent verification means not having
to trust manufacturers’ claims
What is impossible to prove is that proprietary software is more secure
than free, without the public and open inspection of the scientific
community and users in general. This demonstration is impossible
because the model of proprietary software itself prevents this analysis,
so that any guarantee of security is based only on promises of good
intentions (biased, by any reckoning) made by the producer itself, or its
contractors. -Edgar David Villanueva Nunez, Congressman, Peru
The Promise of Open Source
• Popularity among academics and students
increases the pool of knowledgeable
reviewers
• Potential for very fast turnaround time for
security fixes
Opposing Views
Inherently, the closed nature of proprietary software is its first
line of defense regarding security issues…
Opening the code to potential attackers provides a free
education…
-Kenneth Brown, Alexis de Tocqueville Institution
People unfamiliar with the open source model are
accustomed to keeping their source secret. When their source
does become public, it's almost always related to a security
breach or the threat of a security breach.
-Michael Warfield, LinuxWorld
Opposing Views
• Open source gives a short-term advantage
to attackers
– Attackers can find and exploit flaws before
most users can find out about the problem and
apply a fix
• Security breaches bring negative publicity
to a company - there’s an incentive to
conceal information about flaws
Misconceptions
• Too little control over what code goes into a
project
– “If anyone can contribute, how can we trust the
result?”
The GPL does not require `patches to wander in', a big part of the
freedom inherent in it is that the impacted agency has the power to fix a
problem, on the spot, and share the fix at essentially no cost with other
impacted agencies. Trying to do that with proprietary software is
generally illegal.
-Leon Brooks
Misconceptions
• Code that is kept secret is inherently safer
– Kerchoffs’ Principle: The security of an
algorithm should depend only on the key
– Corollary: Minimize the number of secrets that
must be kept to maintain security
Public algorithms are designed to be secure even though they are
public; that's how they're made. So there's no risk in making them
public.
-Bruce Schneier, Crypto-Gram
Misconceptions
• But secrecy is not necessarily unsafe…
Minimize the number of secrets in your security system. To the
extent that you can accomplish that, you increase the robustness of
your security. To the extent you can't, you increase its fragility.
Obscuring system details is a separate decision from making your
system secure regardless of publication; it depends on the availability
of a community that can evaluate those details and the relative
communities of "good guys" and "bad guys" that can make use of
those details to secure other systems. -Bruce Schneier, Crypto-Gram
Misconceptions
• Open source software is inherently safer
– Source availability is no guarantee of effective
review
– Few open source contributors know how to
look for security flaws in code
simply publishing the code does not automatically mean that people
will examine it for security flaws. Security researchers are fickle and
busy people. They do not have the time to examine every piece of
source code that is published. So while opening up source code is a
good thing, it is not a guarantee of security… -Bruce Schneier
Re-Framing the Question
“Is open source code more secure than proprietary code?”
Re-Framing the Question
“Is open source code more secure than proprietary code?”
This is the wrong question.
Re-Framing the Question
New Questions:
• What are the requirements for building and
deploying secure software?
• What aspects of open source development
make these requirements easier or harder?
• What can we do to help the open source
model deliver on its promise of security?
Challenges & Solutions
• Challenge: Responsible Disclosure
– Early disclosure can lead to increased attacks
– but people have a right to know the risks of the
software they use
Those advocating secrecy are right that full disclosure causes damage,
in some cases more damage than good. They are also right that those
who build attack tools should be held liable for their actions; the
defense of "I just built the bomb; I didn't place it or set the fuse" rings
hollow. But they are wrong to think they can enforce secrecy.
Information naturally disseminates, and strategies that go against that
are doomed.
-Bruce Schneier
Challenges & Solutions
• Challenge: Responsible Disclosure
– Companies conceal vulnerabilities and are slow
to provide fixes
– but some “security researchers” disclose
vulnerabilities for personal publicity
Someone who releases a harmful program through a press release has
a different agenda than to help you.
-Bruce Schneier
A large portion of security experts go home at night and write tools
for the script kiddies.
-Marcus Ranum
Challenges & Solutions
• Solution: Limited Initial Disclosure
(A Compromise)
– Limit technical description of vulnerabilities to
a group of experts and stakeholders until bug is
fixed
– Low barrier to entry in the group
– Reporter, group members keep things honest
– Full disclosure after fix is distributed
Challenges & Solutions
• Challenge: Lack of Qualified Reviewers
– Security problems are subtle and often missed
even by expert programmers
• Solution: Finding, Training, and
Incentivizing Bug Hunters
– Training Reviewers to spot problems
– Netscape Bug Bounty Program
Challenges & Solutions
• Challenge: Automating & Systematizing
Security Review
– repeated mistakes
– no feedback to developers
• Solution: Tight Feedback Loops
– Integrate security scanners into build feedback
– Review past problems and integrate findings
into future security evaluations
Challenges & Solutions
• Challenge: Developer Education
• Solution: Identify Common Mistakes &
Teach Best Practices
– We need new, innovative forms of developer
education
Key Sources
• “The Cathedral and the Bazaar,” Eric Raymond
– http://www.tuxedo.org/~esr/writings/cathedral-bazaar
• “Crypto-Gram,” Bruce Schneier, Sep. 1999, Jan. 2000, Feb. 2000, Sep.
2000, May 2002
– http://www.counterpane.com/crypto-gram.html
• “Opening the Open Source Debate,” Kenneth Brown
– available at http://www.adti.net
• “Dispelling Myths about the GPL and Free Software,” John Viega and
Bob Fleck
– http://www.cpi.seas.gwu.edu/oss/cpi_rebuttal.pdf
• “Why Open Source? Look at the Numbers!” David Wheeler
– http://www.dwheeler.com/oss_fs_why.html#security
Questions & Comments
Welcome