Securing Open Source Software: Advantages and Challenges

Mitch StoltzHead 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 beta-tester 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

• 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?

New Questions:

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