20
1 Open Source Software (OSS) and Security MIL-OSS Dr. David A. Wheeler & Jim Barkley August 5, 2010 This presentation contains the views of the author and does not indicate endorsement by IDA or MITRE, the U

Barcamp: Open Source and Security

Embed Size (px)

Citation preview

Page 1: Barcamp: Open Source and Security

1

Open Source Software (OSS) and Security

MIL-OSS

Dr. David A. Wheeler &Jim Barkley

August 5, 2010This presentation contains the views of the author and does not indicate endorsement by IDA or MITRE, the U.S. government, or the U.S. Department of Defense.

Page 2: Barcamp: Open Source and Security

2

OSS & Security

Extreme claims“OSS is always more secure”“Proprietary is always more secure”

Reality: Neither OSS nor proprietary always betterOSS has many potential security advantagesSome specific OSS programs are more secure than their competitors

Evaluate your OSS options!

Page 3: Barcamp: Open Source and Security

3

OSS has many advantages for security (1)

Mass peer reviewIt really happens: Linux reviewed-by, OpenBSD,

Mozilla Bug Bounty, Debian-audit, ...

Multi-tool review (static & dynamic)Vulnerability Discovery and Remediation, Open

Source Hardening Project (DHS/Coverity/Stanford)

Fortify’s “Java Open Review Project”Linux “sparse”

Page 4: Barcamp: Open Source and Security

4

OSS has many advantages for security (2)

Better meets “open design” security principle [Saltzer & Schroeder]“the protection mechanism must not depend on

attacker ignorance”Security experts perceive OSS advantage

Bruce Schneier: “demand OSS for anything related to security”

Vincent Rijmen (AES): “forces people to write more clear code & adhere to standards”

Whitfield Diffie: “it’s simply unrealistic to depend on secrecy for security”

Survey of 6,344 software development managers favored OSS’ security [BZ Research]

Page 5: Barcamp: Open Source and Security

5

Some OSS security statistics

OSS systems scored better on security [Payne, Information Systems Journal 2002]IE 21x more likely to get spyware than Firefox [U of Wash.]Faster response: Firefox 37 days, Windows 134.5 days Browser “unsafe” days in 2004: 98% Internet Explorer, 15% Mozilla/Firefox (half of Firefox’s MacOS-only) Windows websites more vulnerable in practice

17% (GNU/Linux) 66% (Windows)Defaced

66.75% (Apache) 24.81% (IIS)Deployed websites (by name)

29.6% (GNU/Linux) 49.6% (Windows)Deployed Systems

OSSProprietaryCategory

[See http://www.dwheeler.com/oss_fs_why.html ]

Page 6: Barcamp: Open Source and Security

6

DoD cyber security requires OSS

“One unexpected result was the degree to which Security depends on FOSS. Banning FOSS would

remove certain types of infrastructure components (e.g., OpenBSD) that currently help support network security.

... limit DoD access to—and overall expertise in—the use of powerful FOSS analysis and detection applications that hostile groups could use to help stage cyberattacks.

... remove the demonstrated ability of FOSS applications to be updated rapidly in response to new types of cyberattack.

Taken together, these factors imply that banning FOSS would have immediate, broad, and strongly negative impacts on the ability of many sensitive and security-focused DoD groups to defend against cyberattacks.” - Use of Free and Open Source Software in the US Dept. of Defense (MITRE, sponsored by DISA), Jan. 2, 2003

Page 7: Barcamp: Open Source and Security

7

Why hiding source doesn’t help security

Dynamic attacks don’t need source or binary

Observing output from inputs sufficient for attack

Presumes you can keep source secret

Attackers may extract it or legitimately get it

Static attacks can use pattern-matches against binaries

Source code can be regenerated by disassemblers & decompilers sufficiently to search for vulnerabilities

Page 8: Barcamp: Open Source and Security

8

Hiding source doesn’t help security: Look at the reality

CVE is full of vulnerability reports on proprietary productsInc. those from Microsoft, Oracle, Adobe, ...

Hiding source inhibits others from maintaining the software

Hiding source doesn’t appreciably inhibit attacks

Page 9: Barcamp: Open Source and Security

9

Hiding source hurts security

Secrecy inhibits helpers, while not preventing attackers

With OSS, you can wait for supplier or fix it yourself“Wait for supplier” can be a disaster if it’s

important

“Security through obscurity” is widely denigrated

Page 10: Barcamp: Open Source and Security

10

Can “Security by Obscurity” be a basis for security?

“Security by Obscurity” can work, but iff:

Keeping secret actually improves security

You can keep the security-critical information a secret

To keep security-critical information a secret, need to:

Keep source secret from all but a few people. Never sell or reveal source. E.G.: Classify

Keep binary secret; never sell binary to outsiders

Use software protection mechanisms (goo, etc.)

Remove software binary before exporting system

Keep inputs/outputs secret of program to be accessible by others – no Internet/web access

Incompatible with commercial off-the-shelf development

Does not apply to unclassified software

Page 11: Barcamp: Open Source and Security

11

Proprietary advantages…not necessarily (1)

Experienced developers who understand security produce better resultsExperience & knowledge are critical, but...OSS developers often very experienced & knowledgeable too (BCG study: average 11yrs experience, 30 yrs old) – often same peopleProprietary developers higher quality?Dubious; OSS often higher reliability,securityMarket rush often impairs proprietary quality

Page 12: Barcamp: Open Source and Security

12

Proprietary advantages…not necessarily (2)

No guarantee OSS is widely reviewedTrue! Unreviewed OSS may be very insecureAlso true for proprietary (rarely reviewed!). Check it!

Can sue vendor if insecure/inadequate

Nonsense. EULAs forbid, courts rarely accept, costly to sue with improbable results, you want sw not a suit

Page 13: Barcamp: Open Source and Security

13

Does OSS help counter malicious code?

“If the Trojan horse was made of glass, would the Trojans have brought it into the city?” - Bill Vaas

Page 14: Barcamp: Open Source and Security

14

Inserting malicious code & OSS: Basic concepts (1)

“Anyone can modify OSS, including attackers”Actually, anyone can modify proprietary programs too… just use a hex editor. Legal niceties not protection!Trick is to get result into user supply chainIn OSS, requires subverting/misleading the trusted developers or trusted repository/distribution…and no one noticing the public malsource later

Page 15: Barcamp: Open Source and Security

15

Inserting malicious code & OSS: Basic concepts (2)

Distributed source aids detectionLarge community-based OSS projects tend to have many reviewers from many countriesMakes attacks more difficultConsider supplier as you would proprietary softwareRisk larger for small OSS projects

Page 16: Barcamp: Open Source and Security

16

OSS tends to deal with malicious code as well or better

Linux kernel attack – repository insertion

Tried to hide; = instead of ==

Attack failed (CM, developer review, conventions)

Borland InterBase/Firebird back door: OSS helpeduser: politically, password: correctHidden for 7 years in proprietary productFound after release as OSS in 5 monthsUnclear if malicious, but has its form

Page 17: Barcamp: Open Source and Security

17

Acronyms (1)

BSD: Berkeley Software Distribution

COTS: Commercial Off-the-Shelf (either proprietary or OSS)

DFARS: Defense Federal Acquisition Regulation Supplement

DISR: DoD Information Technology Standards and Profile Registry

DoD: Department of Defense

DoDD: DoD Directive

DoDI: DoD Instruction

EULA: End-User License Agreement

FAR: Federal Acquisition Regulation

OSS: Free-libre / Open Source Software

FSF: Free Software Foundation (fsf.org)

GNU: GNU’s not Unix

GOTS: Government Off-The-Shelf (see COTS)

GPL: GNU General Public License

HP: Hewlett-Packard Corporation

IPR: Intellectual Property Rights; use “Intellectual Rights” instead

IT: Information Technology

LGPL: GNU Lesser General Public License

Page 18: Barcamp: Open Source and Security

18

Acronyms (2)

MIT: Massachusetts Institute of Technology

MPL: Mozilla Public License

NDI: Non-developmental item (see COTS)

OMB: Office of Management & Budget

OSDL: Open Source Development Labs

OSI: Open Source Initiative (opensource.org)

OSJTF: Open Systems Joint Task Force

OSS: Open Source Software

PD: Public Domain

PM: Program Manager

RFP: Request for Proposal

RH: Red Hat, Inc.

ROI: Return on Investment

STIG: Security Technical Implementation Guide

TCO: Total Cost of Ownership

U.S.: United States

USC: U.S. Code

V&V: Verification & Validation

Trademarks belong to the trademark holder.

Page 19: Barcamp: Open Source and Security

19

Interesting Documents/Sites

“Why OSS/FS? Look at the Numbers!” http://www.dwheeler.com/oss_fs_why.html“Use of Free and Open Source Software in the US Dept. of Defense” (MITRE, sponsored by DISA) President's Information Technology Advisory Committee (PITAC) -- Panel on Open Source Software for High End Computing, October 2000“Open Source Software (OSS) in the DoD,” DoD memo signed by John P. Stenbit (DoD CIO), May 28, 2003Center of Open Source and Government (EgovOS) http://www.egovos.org/OpenSector.org http://opensector.orgOpen Source and Industry Alliance http://www.osaia.orgOpen Source Initiative http://www.opensource.orgFree Software Foundation http://www.fsf.orgOSS/FS References http://www.dwheeler.com/oss_fs_refs.html

Page 20: Barcamp: Open Source and Security

20

License

This set of slides is released under the Creative Commons Attribute (CC-BY) license 3.0