Securing Open Source Software: Advantages and Challenges

1
Securing Open Source Software Advantages and
Challenges

• Mitch Stoltz
• Head Security Engineer
• Netscape Client Products Division

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

3
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
4
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

5
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
6
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

7
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
8
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 - theres an incentive to conceal
  information about flaws

9
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
10
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
11
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
12
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

13
Re-Framing the Question
Is open source code more secure than proprietary
code?
14
Re-Framing the Question
Is open source code more secure than proprietary
code?
This is the wrong question.
15
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?

16
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
17
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
18
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

19
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

20
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

21
Challenges Solutions

• Challenge Developer Education
• Solution Identify Common Mistakes Teach Best
  Practices
• We need new, innovative forms of developer
  education

22
Key Sources

• The Cathedral and the Bazaar, Eric Raymond
• http//www.tuxedo.org/esr/writings/cathedral-baza
  ar
• 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.htmlsecurity

23
Questions Comments Welcome