"CERT Secure Coding Standards" by Dr. Mark Sherman

2015 Carnegie Mellon University

04-Nov-2015

CERT Secure Coding Standards (and the Secure Software Development Lifecycle)Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213

Mark Sherman, PhDTechnical Director, [email protected]

2

Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University

Copyright 2015 Carnegie Mellon University

This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center.

Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense.

References herein to any specific commercial product, process, or service by trade name, trade mark, manufacturer, or otherwise,does not necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software Engineering Institute.

NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN AS-IS BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

This material has been approved for public release and unlimited distribution.

This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at [email protected].

Carnegie Mellon and CERT are registered marks of Carnegie Mellon University.

DM-0002969

3


State of software Building software: the Secure Software

Development Lifecycle Security in Agile Available standards Rule development methodology Example weaknesses New developments in secure coding Adoption of secure coding Review

Agenda

4


Software vulnerabilities are ubiquitous

5


Software and security failures are expensive

Source: New York Times, Jan 10, 2014

Average cost in a breach:US$188 per record

Source: Ponemon Institute, 2013 Cost of Data Breach Study: Global Analysis, May 2013

Source: Wall Street Journal, Feb 26, 2014

6


An ounce of prevention .

We wouldn't have to spend so much time, money, and effort on network security if we didn't have such bad software security.

Bruce Schneier in Viega and McGraw, Building Secure Software, 2001

Source: Washington Post, March 19, 2014, http://www.washingtonpost.com/business/economy/toyota-reaches-12-billion-settlement-to-end-criminal-probe/2014/03/19/5738a3c4-af69-11e3-9627-c65021d6d572_story.html; http://www.greene-broillet.com/Articles/Toyotasuddenacceleration.shtml

http://www.washingtonpost.com/business/economy/toyota-reaches-12-billion-settlement-to-end-criminal-probe/2014/03/19/5738a3c4-af69-11e3-9627-c65021d6d572_story.html

7


Catching software faults early saves moneyFaults accounts for 3050% percent of total software project costs

Sources: Critical Code; NIST, NASA, INCOSE, and Aircraft Industry Studies

8




Agenda

9


Focus on the need to develop the theory, processes, practices and technology to support the agile construction and maintenance of

secure software

Security is a lifecycle issue

10


Software security is not security software

Not the same as security software Firewalls, intrusion detection, encryption Protecting the environment within which the software operates

Engineering software so that it continues to function under attackThe ability of software to recognize, resist, tolerate, and recover from events that threaten itGoal: Better, defect-free software that can function more robustly in its operational production environment

In government circles, this is frequently called Software Assurance Microsoft (and hence the commercial world) has a different interpretation

of software assurance

11


Room for improvement

Mission thread(Business process)

19% fail to carry out security requirement

definition

27% do not practice secure design

72% do not use code or binary analysis

47% do not perform acceptance tests for third-party code

More than 81% do not coordinate their security practices in various stages of the development life cycle.

Sources: Forrester Consulting, State of Application Security, January 2011; Wendy Nather, Research Director, 451 Research, Dynamic testing: Why Tools Alone Aren't Enough, March 25, 2015

12


Most Vulnerabilities Are Caused by Programming Errors

64% of the vulnerabilities in the National Vulnerability Database were due to programming errors 51% of those were due to classic errors like buffer overflows, cross-site scripting,

injection flaws

Top 25 CWE includes Integer overflow Buffer overflow Missing authentication Missing or incorrect authorization Reliance on untrusted inputs (aka tainted inputs)

Sources: Heffley/Meunier (2004): Can Source Code Auditing Software Identify Common Vulnerabilities and Be Used to Evaluate Software Security?; cwe.mitre.org/top25 Jan 6, 2015

13


Code security quality reviews generally reveal problems

Source: http://xkcd.com/1513/

14


There is a wide range of application security quality

0

50

100

150

200

250

1 2 3 4 5 6 7 8 9 10 11

Dia

gnos

tics

per

KsL

OC

Program

Source: CERT sample of evaluated programs

15




Agenda

16


Integrating security into Agile development1. Code hygiene introduce secure coding2. Secure DevOps include security tools3. Threat modeling represent a new role4. Risk analysis prioritize in backlog

Personanon grata

Code hygieneSecure DevOps

Threat modeling

Risk analysis

(See also: Bellomo and Woody, DoD Information Assurance and Agile: Challenges and Recommendations Gathered Through Interviews with Agile Program Managers and DoD Accreditation Reviewers(http://repository.cmu.edu/cgi/viewcontent.cgi?article=1674&context=sei)

http://repository.cmu.edu/cgi/viewcontent.cgi?article=1674&context=sei

17




Agenda

18


CERT Secure Coding StandardsCERT C Secure Coding Standard

Version 1.0 (C99) published in 2009 Version 2.0 (C11) published in 2014 ISO/IEC TS 17961 C Secure Coding Rules Technical

Specification Conformance Test Suite

CERT C++ Secure Coding Standard Version 1.0 under development

CERT Oracle Secure Coding Standard for Java Version 1.0 (Java 7) published in 2011 Java Secure Coding Guidelines Subset applicable to Android development Android Annex

The CERT Perl Secure Coding Standard Version 1.0 under development

CERT Python Secure Coding Standard Version 1.0 under development

19


Coding rules

Collected wisdom of programmers and tools vendors Fed by community wiki started in

Spring 2006 1,576 registered contributors

Basis for ISO Standard

20


Secure Coding eNewsletter engages community

21




Agenda

22


Common methodology for determining rules and practices

Source: https://www.youtube.com/watch?v=JN99jshaQbY

23


Examine language definitions and standards for undefined and unspecified behavior

Source: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pd (ISO 9899 - Programming Languages C draft)

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pd

24


Examine vulnerable code for patterns

Malware repository with millions of unique, tagged artifacts

CERT Secure Coding Team has evaluated over 100M LOC

25


Implement candidate rules and run against sample code

Focus rule when possible to maximize true positive of weakness (tag bad code) minimize false negative of weakness (dont tag good code)

Write program to evaluate source code for particular rule

Run program against collection of known bad source code and a collection of other (suspected good) code to check sensitivity and specificity of results

26


Tapping into expert knowledge for developing CERT coding standards

Engage community

Tool vendor analysis

Consensus on

vulnerability and

mitigation

27


Risk assessment methodology

Risk assessment is performed using failure mode, effects, and criticality analysis.

SeverityHow serious are the consequences of the rule being ignored?

Value Meaning Examples of Vulnerability

1 low denial-of-service attack, abnormal termination

2 medium data integrity violation, uninten-tional information disclosure

3 high run arbitrary code

LikelihoodHow likely is it that a flaw introduced by ignoring the rule can lead to an exploitable vul-nerability?

Value Meaning

1 unlikely 2 probable 3 likely

CostThe cost of mitigating the vulnerability.

Value Meaning Detection Correction

1 high manual manual 2 medium automatic manual 3 low automatic automatic

28




Agenda

29


What Is a Buffer Overflow?A buffer overflow occurs when data is written outside of the boundaries of the memory allocated to a particular data structure.

DestinationMemory

SourceMemory

Allocated Memory (12 Bytes) Other Memory

16 Bytes of Data

Copy Operation

30


Buffer Overflows

Are caused when buffer boundaries are neglected and uncheckedCan occur in any memory segmentCan be exploited to modify a variable data pointer function pointer return address on the stack

Smashing the Stack for Fun and Profit (Aleph One, Phrack49-14, 1996) provides the classic description of buffer overflows.

31


Buffer overflow: potentially surprising undefined behavior from integer overflowUnintended optimization can happen once any undefined behavior occurs in the program. Consider the following example:if (x < 0) x = 0;if (((x + 1) >> 30) /* x is 32-bit signed int >= 0 */) {

A[1] = y; } else {A[0] = y;

}When defined, ((x + 1) >> 30) always produces 0 or 1. An implementation could condense the entire if statement into

A[((x + 1) >> 30)] = y;But if x + 1 overflows, some platforms could produce 2 or -2. Since signed integer overflow is Undefined Behavior, this is permitted by the standard.

32


Adding a Pointer and an Integer

From C99 6.5.6p8:When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand. An expression like P[N] is translated into *(P+N).

33


Adding a Pointer and an Integer

C99 Section 6.5.6 saysIf both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated.

34


Buffer overflow: surprising integer overflow

A programmer might code a bounds-check such as

char *ptr; // ptr to start of arraychar *max; // ptr to end of arraysize_t len; // input unknown to programmer if (ptr + len > max)return EINVAL;

If len is very large, it can cause ptr + len to overflow, which creates undefined behavior. A result would typically wrap-aroundpointing to an address that is actually lower in memory than ptr. Since (overflowed) ptr + len is less than max, execution proceeds

35


Buffer overflow: surprising code elimination

One might write a check like this:if (ptr + len < ptr || ptr + len > max)return EINVAL;

A compiler could assume that Programs are defined Hence a ptr + len will not overflow Hence, since len is unsigned, ptr + len must be

greater than or equal to (not less than) ptr Hence ptr + len < ptr is always true and can be

removed as dead code

36


Algebraic Simplification

Optimizations may be performed for comparisons between P + V1 and P + V2 where P is the same pointer V1 and V2 are variables of some integer type.

As a common term, P might be eliminated thru simplification.

37


Buffer overflow: surprising optimization

In our example: if (ptr + len < ptr || ptr + len > max)return EINVAL;

This optimization proceeds as follows:ptr + len < ptrptr + len < ptr + 0ptr + len < ptr + 0len < 0 (impossible, len is unsigned)

The rewritten len < 0 is removed.

38


Mitigation

This problem is easy to remediate, once it is called to the attention of the programmer, such as by a diagnostic message when dead code is eliminated. For example, if it is known that ptr is less-or-equal-to max, then the programmer could write:

if (len > max ptr)return EINVAL;

This conditional expression eliminates the possibility of undefined behavior.

39


Learning from rules and recommendations

Rules and recommendations in the secure coding standards focus to improve behavior

The Ah ha moment: Noncompliant code examples or antipatternsin a pink framedo not copy and paste into your code

Compliant solutions in a blue frame that conform with all rules and can be reused in your code

40




Agenda

41


Some recent additions explore threads and C++ updates

Major language updates forC++

24 new rules in FY15 specifying C++ weaknesses

60 existing C++ rules updated in FY15

New and updated rules published on http://www.cert.org/secure-coding/publications/secure-coding-enewsletter.cfm

New computation model: C threads

9 unspecified behaviors representing programming weaknesses in two broad categories Inter-thread communication Thread-specific storage

Example: the tss_create function which creates thread-specific storage and assigns a destructor but does not specify when the destructor is called.

42


Extending secure coding rules to new models

Secure coding forconcurrent programming

Designing secureAPIs

43


C and C++ Thread Safety Analysis

CERT and Google developed thread safety analysis for Clang uses annotations to declare and static analysis to enforce thread safety

policies in C and C++ programs detects potential race conditions and deadlocks Clang is a production-quality C and C++ compiler available on most platforms the analysis is using the -Wthread-safety flag

Annotation usage: Have not been a liability Benefits software

evolution and maintenance Establish rules regarding which roles may execute particular code segments, e.g. REQUIRES(FlightControl)

DataLogger REQUIRES(DataLogger)

Declare roles threads may perform, e.g. FlightControl

44


Android App Sets: Sensitive Dataflow

Problem: Colluding apps, or a combination of a malicious app and leaky app can use intents (messages sent to Android app components) to extract sensitive or private information from an Android phone.Goal: Precisely detect tainted flows from sensitive information sources to restricted sinks.

If such flows are discovered: User might refuse to install app App store might remove app

DidFail analysis currently performs 2-phase static taint flow analysis for app sets.Goal is to add context sensitivity, which adds precision, resulting in less false positives.

sinksrc

45


Source to source code correctionprintf(attacker_string) Automated transformation of

insecure C source code Most frequently encountered

mistakes No loss of desired function Changes made at developer

view of source code

Adoption of program transformers Analysis of current systems Addition of specialized

requirements

void lcstr(char *str, size_t size) {

for (size_t i = 0; i < size; i++) {

str[i] = tolower(str[i]);

}

}

printf("%s", attacker_string)

void lcstr(char *str, int size) {

for (int i = 0; i < size; i++) {

str[i] = tolower(str[i]);

}

}

(And all callers of lcstr)

46




Agenda

47


Secure Coding in C/C++ Training

The Secure Coding course is designed for C and C++ developers. It encourages programmers to adopt security best practices and develop a security mindset that can help protect software from tomorrows attacks, not just todays.

Topics String management Dynamic memory management Integral security Formatted output File I/O

Additional information at http://www.sei.cmu.edu/training/p63.cfm

http://www.sei.cmu.edu/training/p63.cfm

48


Secure Coding in Java Workshop

Trust and Security PoliciesValidation and SanitizationThe Java Security ModelDeclarationsExpressionsObject OrientationMethodsVulnerability Analysis Exercise

Numerical Types in JavaExceptional BehaviorInput/OutputSerializationThe Runtime EnvironmentIntroduction to Concurrency in JavaAdvanced Concurrency Issues

The Secure Coding workshop is designed to improve the secure use of Java. Designed primarily for Java SE 8 developers, the workshop is useful to developers using older versions of the platform as well as Java EE and ME developers. Tailored to meet the needs of a development team, the workshop can cover security aspects of:

49


Training delivery options

Conventional classroom Self-study

Written materials On-demand, on-line training: STEPfwd

Hands-on Individual Team

Testing and certificates Workshops, mentoring and advising

50


Tools encourage application of secure codingMoving rules into IDE improves application of secure coding

Early feedback corrects errors on introduction Exceptions are understood in context Feedback improves developer skill

Target Clang static analyzer (C based languages)

Widely used open source front end for popular compilers

Integrated into Apples Xcode IDE

Target FindBugs (Java) Integrated into Eclipse and JDeveloper

Adoption of secure coding IDEs: Help deploy tools Training on tools Extend tools to meet targeted needs

51


Static Testing Source code analysis tools

Secure Code Analysis Laboratory (SCALe) C, C++, Java, PERL, Python, Android

rule conformance checking Thread safety analysis Information flows across Android

applications Operating system call flowsStatic testing optimization SCALe set up SCALe filters and visualizer Tool conformance and capability testing Multitool integration and statistical

optimizer

52


SCALe Multitool evaluationImprove expert review productivity by focusing on high priority violations

Filter select secure coding rule violations

Eliminate irrelevant diagnostics

Convert to common CERT Secure Coding rule labeling

Single view into code and all diagnosticsMaintain record of decisions

53


SCALe Web App DemosWatch demonstration videos of SCALe on YouTube:http://www.cert.org/secure-coding/products-services/scale.cfm

Play next Play now

Source Code Analysis Laboratory (SCALe) Demo: Web UI Columns 8:04

Play next Play now

Source Code Analysis Laboratory (SCALe) Demo Web UI Heading 4:43

Play next Play now

Source Code Analysis Laboratory (SCALe) Demo: Web UI Code 3:01

http://www.cert.org/secure-coding/products-services/scale.cfmhttps://www.youtube.com/watch?v=46LdrI7AkUE&index=1&list=PLSNlEg26NNpxMofZSX-72rxjFEUk9myk-https://www.youtube.com/watch?v=HbpEqxc0W3U&index=2&list=PLSNlEg26NNpxMofZSX-72rxjFEUk9myk-https://www.youtube.com/watch?v=Wc-bS_ro2dk&index=3&list=PLSNlEg26NNpxMofZSX-72rxjFEUk9myk-

54


Optimizing multitool evaluations - research

Analyzers

Analyzers

Analyzers

Diagnostics from each

tool

Expert (Oracle)

Code Repositories

Prioritized diagnostics

list

Analyzers

Analyzers

Analyzers

Diagnostics from each

tool

TestCode

Active ML with STEM

Learn ApplyCode

Metadata

55


Static Testing Source code review

Manual review against threat models Web services: SOAP, REST, XML-RPC Java applets Access control matrices Custom network or data protocols

56


Dynamic testing and evaluation fuzzing

Fuzz testing of attack surfaces Based on techniques used in CERTs Basic

Fuzzing Framework (BFF) mutational fuzzing machine learning and evolutionary computing

techniques adjusts its configuration parameters based on what

it finds (or does not find) over the course of a fuzzing campaign

57


Dynamic testing Penetration testing

Examination of business logic and interfaces, from an adversarial perspective Creating attack models Searching for holes in attack surfaces

Environmental alteration Reverse engineering

Replicates the intended deployment environment for the application Find ways to gain unauthorized access to data or the underlying systems. Documenting program-specific protocols Identifying failure states that are handled in an insecure manner.

58




Agenda

59


Automation; Acquisition (Supply chain); Building skills (Workforce development); Metrics, Models, and Measurement

Review: Secure Software Development Lifecycle

Mission Ready Diagnostics;Threat Modeling;

SQUARE;Security Engineering

Risk Analysis

Architecture Analysis & Design Language

Team Software Process;Secure Agile;

Secure Coding;SCALe

Run time support;

Vulnerability Analysis

Forensic Operations

& Investigations

Software Assurance Framework

60


Contact Information

Mark Sherman(412) 268-9223

[email protected]

Web Resources (CERT/SEI)http://www.cert.org/http://www.sei.cmu.edu/

61


CERT Secure Coding Standards (and the Secure Software Development Lifecycle)Slide Number 2AgendaSoftware vulnerabilities are ubiquitousSoftware and security failures are expensiveAn ounce of prevention .Catching software faults early saves moneyAgendaFocus on the need to develop the theory, processes, practices and technology to support the agile construction and maintenance of secure softwareSoftware security is not security softwareRoom for improvementMost Vulnerabilities Are Caused by Programming ErrorsCode security quality reviews generally reveal problemsThere is a wide range of application security qualityAgendaIntegrating security into Agile developmentAgendaCERT Secure Coding StandardsCoding rulesSecure Coding eNewsletter engages communityAgendaCommon methodology for determining rules and practicesExamine language definitions and standards for undefined and unspecified behaviorExamine vulnerable code for patternsImplement candidate rules and run against sample codeTapping into expert knowledge for developing CERT coding standardsRisk assessment methodologyAgendaWhat Is a Buffer Overflow?Buffer OverflowsBuffer overflow: potentially surprising undefined behavior from integer overflowAdding a Pointer and an IntegerAdding a Pointer and an IntegerBuffer overflow: surprising integer overflow Buffer overflow: surprising code elimination Algebraic SimplificationBuffer overflow: surprising optimizationMitigationLearning from rules and recommendationsAgendaSome recent additions explore threads and C++ updatesExtending secure coding rules to new modelsC and C++ Thread Safety AnalysisAndroid App Sets: Sensitive DataflowSource to source code correctionAgendaSecure Coding in C/C++ TrainingSecure Coding in Java WorkshopTraining delivery optionsTools encourage application of secure codingStatic Testing Source code analysis toolsSCALe Multitool evaluationSCALe Web App DemosOptimizing multitool evaluations - researchStatic Testing Source code reviewDynamic testing and evaluation fuzzingDynamic testing Penetration testingAgendaSlide Number 59Contact InformationSlide Number 61

Date post:	23-Feb-2017
Category:	Technology
Upload:	owasprinaldi
View:	553 times
Download:	0 times

"CERT Secure Coding Standards" by Dr. Mark Sherman

Technology