gimme shelter: tips on protecting proprietary and open source code

1© 2016 Rogue Wave Software, Inc. All Rights Reserved.

1

Gimme shelter: Tips on protecting proprietary and open source code

Rod Cope, CTOESC Minneapolis 2016


2

Rod Cope, CTORogue Wave Software

Presenter


3

Agenda

• Top security defects–Research methodology–Vulnerabilities countdown–Best practices for

prevention• Legal considerations• Q&A


4

Top security defects


5

Research methodology


6

National Vulnerability Database

MITRE

Categorized 8000+ NVD entries from 2015 as embedded or not

Filtered to include only those vulnerabilities with an identified CWE

Sorted list and added up the numbers

Research methodology


7

Vulnerabilities countdown


8

Cryptographic issuesCWE-310: Weaknesses related to the use of cryptography


Numeric errorsCWE-189: Improper calculation or conversion of numbers

10

Remediation: provide clear bounds, sanity check all calculated variables, detect overflows, etc.

Remediation: review design with crypto expert, validate errors are checked, verify non-standard control flow, etc.

9


9

Number eight: Code injection


10

Code injection

CWE-94: Improper control of generation of code

• Primarily affects interpreted environments such as PHP, Perl, or Python, so less common in most embedded environments

• Can affect black box components containing unexpected interpreters (Type 1 or TrueType fonts, PostScript, PDF, etc.)

3.7%


11

Example: Windows RT

CVE-2015-0093http://technet.microsoft.com/security/bulletin/MS15-021

Adobe Font Driver allows remote attackers to execute arbitrary code via a crafted (1) web site or (2) file, aka "Adobe Font Driver Remote Code Execution Vulnerability”

http://technet.microsoft.com/security/bulletin/MS15-021




12

Code injection: remediation

Identify all black box components and ensure you’re using most recent

Identify use of unsafe data as it flows through system (e.g. SQL injection attacks) with tools

Carefully clean any externally acquired information before using system, shell, scripting, or SQL

Design review

Automated static analysis

Manual analysis


13

Resource management errorsCWE-399: Improper management of system resources


Code weaknessesCWE-17: Weaknesses introduced during development,

includingspecification, design, and implementation

7

Remediation: use well-identified coding patterns, create consistent API contracts, identify unclean code, etc.

Remediation: examine assumptions, add C++ wrappers to prevent misused/dangling resources, use fuzz testing, etc.

6


14

Number five: Improper access control


15

Improper access control

CWE-284: Software does not restrict or incorrectly restricts access to a resource from unauthorized actor

7.1%

• Improper privilege management• Improper ownership management• Improper authorization• Incorrect user management• Improper authentication• Origin validation error• Improper restriction of

communication channel to intended endpoints


16

Example: stunnel (TLS proxy)

CVE-2015-3644https://www.stunnel.org/CVE-2015-3644.html

stunnel when using the redirect option, does not redirect client connections to the expected server after the initial connection, which allows remote attackers to bypass authentication

https://www.stunnel.org/CVE-2015-3644.html

https://www.stunnel.org/CVE-2015-3644.html


17

stunnel example: fail


18

stunnel example: fix


19

Improper access control: remediationVery carefully manage setting, management, and handling of privileges

Architecture and design

Compartmentalize system with safe areas that have unambiguous trust boundaries, don’t allow sensitive data to leave trust boundary, exercise caution when interfacing outside of trust boundary

Use principle of least privilege to decide when to drop system privileges


20

Information exposureCWE-200: Intentional or unintentional disclosure of information to

an actor not explicitly authorized

Vulnerabilities countdown Improper input validation

CWE-20: Incorrect or missing validation on input that can affect program’s control flow or data flow

4Remediation: assume all data is malicious, check data on both client and server-side, use same character encodings, etc.

Remediation: perform weakness analysis, compartmentalize system, perform fuzz testing, etc.

3

Access controlCWE-264: Weaknesses related to the management of permissions,

privileges, or other security features

Remediation: perform weakness analysis, examine the granting of access controls, etc.

2


21

Number one: Memory buffer problems


22

Memory buffer problems

CWE-119: Software can read or write to locations outside of the boundaries of the memory buffer

25.6%

• Not checking size of input on copy• Bug allowing writing to arbitrary

locations• Out-of-bounds read• Pointers outside expected range• Untrusted pointer dereference• Uninitialized pointers• Expired pointer references• Access of memory beyond buffer end


23

Example: GNU libc

CVE-2015-1472https://sourceware.org/ml/libc-alpha/2015-02/msg00119.html

Under certain conditions wscanf can allocate too little memory for the to-be-scanned arguments and overflow the allocated buffer. The implementation now correctly computes the required buffer size when using malloc

https://sourceware.org/ml/libc-alpha/2015-02/msg00119.html

https://sourceware.org/ml/libc-alpha/2015-02/msg00119.html


24

GNU libc example: fail


25

GNU libc example: fix


26

Memory buffer problems: remediation

Use to easily identify most problems of this type

Perform fuzz testing

Carefully examine all buffer access

Automated static code analysis

Dynamic code analysis

Manual code analysis


27

Best practices for prevention


28

Awareness

Awareness of these top ten issues can help with nearly 90% of all vulnerabilities in embedded software

87.5%


29

Top four best practices

•Numeric errors•Code injection•Resource management errors

• Improper input validation• Information exposure•Access control•Memory buffer problems

• Numeric errors• Cryptographic issues• Code injection• Code• Resource management errors• Information exposure• Access control• Memory buffer problems

•Numeric errors•Cryptographic issues•Code injection•Code•Resource management errors

• Improper input validation

•Numeric errors•Resource management errors• Improper access control• Improper input validation• Information exposure•Access control

Clean design

Methodical process

Good tools

Careful analysis


30

Legal considerations


31

History of licensing

19911988 2001 2004 2007 2012

BSD & MITLicenses

GPLv2 Apache 2.0 GPLv3 MPL 2.0CPL

· Implied License &/or Estoppel

· Implied License &/or Estoppel · Patent Disincentive Clause

· Express Patent License· Patent RetaliationClause

· Broad Express Patent License· Anti-Tivoization clause· Patent Non-Assert· Patent Disincentive Clause

· Express Patent License· Patent RetaliationClause


32

Example: GPL/GPL license compatibility

http://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility


33

Case study: Welte v. Fantec (Germany)• GPLv2.0 software used in a media player• Fantec : Fantec’s supplier assured them compliance

with GPL terms.• Result: Welte was awarded Attorney’s fees and damages.• German Court stated:

– “Here, Defendant was not allowed to rely merely on its suppliers’ assurances that the works supplied did not infringe any third-party rights.

– In any case, Defendant should have performed its own review of the software, or have someone preform, by hiring knowledgeable third parties, such a review of the software offered and provided by Defendant – even if this would have resulted in additional costs.”


34

Step 1: Have a license policy

• You must decide which licenses are acceptable for your company (and potentially your customers).

• The policy depends on how you plan to use the software.

• GENIVI has the following policy– Red – GPLv3; LGPLv2/3; BSD 4; MPL1.1; Flora– Yellow – GPLv2; LGPL2.1; AFL 3; OSL 3; OpenSSL; Public

domain– Green – MPL 2.0; BSD 2/3; MIT/X11; Apache 1.1/2;

Artistic 2/1


35

Step 2: Educate developers

• Which software/licenses are acceptable and not

• Which software licenses need to be discussed

• How and who to contact with questions – Point Person

• Disclosure of software use to Point Person


36

Step 3: Compliance

Apple - iPhone

Mercedes-Benz


37

Roadmap to compliance

• 1st appreciate open source software’s benefits• 2nd develop an open source software strategy• 3rd know your code: education, Point Person• 4th know the licenses associated with your code• 5th comply or use different software


38

Q & A


39