Secure Coding Becomes Standard - DTIC PDF Free Download

1y ago

45 Views

1 Downloads

3.18 MB

39 Pages

Report/dmca

Download PDF

Transcription

Why Care about Software Security?Vulnerabilities allow attackers to compromise information security confidentialityintegrityavailabilityAccurate risk assessment requires knowledgeabout vulnerabilities prerequisite conditionstechnical detailsimpacts and mitigation strategiesIncreased risk to information and communication systems critical infrastructures are affected (and often unprepared to respond)software used by control systems vulnerable to attackconvergence of common technologiesadversaries leverage failures in technology and people to conduct criminal activityeconomic and physical consequences of cyber attacks 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 3

Most Vulnerabilities caused byProgramming Errors64% of the vulnerabilities in NVD in 2004 are due toprogramming errors 51% of those due to classic errors like buffer overflows, cross-site-scripting, injection flaws Heffley/Meunier (2004): Can Source Code Auditing Software IdentifyCommon Vulnerabilities and Be Used to Evaluate Software Security?Cross-site scripting, SQL injection at top of thestatistics (CVE, Bugtraq) in 2006"We wouldn't need so much network security if wedidn't have such bad software security"--Bruce Schneier 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 5

Information Warriors8 nations have developed cyber-warfare capabilities comparable to thatof the United States.More than 100 countries are trying to develop them. 23 nations havetargeted U.S. systems.North Korea, Libya, Iran, and Syria reportedly have some capability.Russia, China, India, and Cuba have acknowledged policies of preparingfor cyber-warfare and are rapidly developing their capabilities.China is moving aggressively toward incorporating cyber-warfare into itsmilitary lexicon, organization, training, and doctrine. It has the capabilityto penetrate poorly protected U.S. computer systems and potentiallycould use computer network attacks to strike specific U.S. civilian andmilitary infrastructures. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 6

Unexpected Integer ValuesAn unexpected value is oneyou would not expect to getusing a pencil and paperUnexpected values are a common source of softwarevulnerabilities. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 8

Fun with Integerschar x, y;x -128;y -x;if (x y) puts("1");if ((x - y) 0) puts("2");if ((x y) 2 * x) puts("3");if (((char)(-x) x) ! 0) puts("4");if (x ! -y) puts("5"); 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 9

CERT Secure Coding StandardsIdentify coding practices that can be used to improvethe security of software systems under developmentCoding practices are classified as either rules orrecommendations Rules need to be followed to claim compliance. Recommendations are guidelines or suggestions.Development of Secure Coding Standards is acommunity effort 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 10

ScopeThe secure coding standards proposed by CERT are basedon documented standard language versions as defined byofficial or de facto standards organizations.Secure coding standards are under development for: C programming language (ISO/IEC 9899:1999) C programming language (ISO/IEC 14882-2003 )Applicable technical corrigenda and documented languageextensions such as the ISO/IEC TR 24731 extensions to the Clibrary are also included. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 11

RulesCoding practices are defined as rules when Violation of the coding practice will result in a securityflaw that may result in an exploitable vulnerability. There is an enumerable set of exceptional conditions (orno such conditions) where violating the coding practice isnecessary to ensure the correct behavior for theprogram. Conformance to the coding practice can be verified. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 13

RecommendationsCoding practices are defined as recommendationswhen Application of the coding practice is likely to improvesystem security. One or more of the requirements necessary for a codingpractice to be considered as a rule cannot be met. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 16

MEM00-A. Allocate and free memory in the samemodule, at the same level of abstractionAllocating and freeing memory in different modules and levelsof abstraction burdens the programmer with tracking thelifetime of that block of memory.This may cause confusion regarding when and if a block ofmemory has been allocated or freed, leading to programmingdefects such as double-free vulnerabilities, accessing freedmemory, or writing to unallocated memory.To avoid these situations, it is recommended that memory beallocated and freed at the same level of abstraction, andideally in the same code module.Freeing memory in different modules resulted in a vulnerabilityin MIT Kerberos 5 MITKRB5-SA-2004-002 . 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 17

Community Development ProcessRules are solicitedfrom the communityPublished as candidate rules and recommendationson the CERT Wiki at:www.securecoding.cert.orgThreaded discussions used for public vettingCandidate coding practicesare moved into a securecoding standard whenconsensus is reached 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 18

Priorities and LevelsHigh severity,likely,inexpensive torepair flawsL1 P12-P27L2 P6-P9L3 P1-P4Low severity,unlikely,expensive torepair flawsMed severity,probable, medcost to repairflaws 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 19

Relating Vulnerability Notes to Secure Coding RulesVulnerability Note VU#649732This vulnerability occurred as aresult of failing to comply with ruleFIO30-C of the CERT CProgramming Language SecureCoding Standard.CERT Secure Coding StandardUS CERT Technical AlertsExamples of vulnerabilitiesresulting from the violationof this recommendation canbe found on the CERTwebsite . 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 22

ApplicationsEstablish secure coding practices within an organization may be extended with organization-specific rules cannot replace or remove existing rulesTrain software professionalsCertify programmers in secure codingEstablish base-line requirements for software analysis toolsCertify software systems’ compliance with secure coding rules 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 23

International Standards ProjectProject title: Avoiding Vulnerabilities in ProgrammingLanguages through Language Selection and UseInitiated in September 2005Assigned to a cross-cutting group, OWGV (ISOjargon for Other Working Group on Vulnerability) Intended to work collaboratively with language-specificworking groups of SC 22 May provide recommendations to language-specificworking groups for changing language specificationsProduct will be an ISO Technical Report – not astandardPublication of report is planned for January 2009. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 25

Participating National BodiesCanadaSCCSteve MichellFranceAFNORFranco GasperoniGermany (observing)DINRoman GrahleItalyUNITullio VardanegaJapanJSAKiyoshi IshihataUKBSI IST-5Derek JonesUSAINCITS CT22Rex Jaeschke 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 26

Other ParticipantsBen BrosgolHal BurchPaul CaseleyRod ChapmanCesar Gonzalez-PerezBarry HedquistChris HillsFred LongBob MartinEd de MoelOlwen MorganDan NagleErhard PloederederTom PlumClive PygottRobert SeacordBill SpeesBarry TauberTucker TaftLarry WagonerBrian WichmannRT/SC JavaCERTUK MODSPARKJTC 1/SC 7/WG 19MISRA CCERTCVE, CWEMDC (MUMPS)WG5 (Fortran), J3 (Fortran)WG9 (Ada), Ada-EuropeWG14 (C), ECMA TC39 / TG2 (C#)MISRA C CERTFDAWG4 (Cobol), J4 (Cobol)SIGAda 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 27

Four AudiencesSafety: Products where it is critical to preventbehavior which might lead to human injury, and it isjustified to spend additional development moneySecurity: Products where it is critical to secure dataor access, and it is justified to spend additionaldevelopment moneyPredictability: Products where high confidence in theresult of the computation is desiredAssurance: Products to be developed fordependability or other important characteristics 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 28

OWG: Vulnerability Status 1The project has two officers Convener, John Benito Secretary, Jim Moore Still need an EditorA skeleton document has been completed.A template for vulnerability descriptions has beencompleted.An initial set of vulnerabilities has been proposed fortreatment. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 29

OWG: Vulnerability Status 2The body of Technical Report describesvulnerabilities in a generic manner, including: Brief description of application vulnerability Cross-reference to enumerations, e.g. CWE Categorizations by selected characteristics Description of failure mechanism, i.e. how codingproblem relates to application vulnerability Points at which the causal chain could be broken Assumed variations among languages Ways to avoid the vulnerability or mitigate its effectsAnnexes provide language-specific treatments ofeach vulnerability. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 30

OWG: Vulnerability Status 3OWGV maintains a web site for its work:http://aitc.aitcnet.org/isai/Meeting schedule: OWGV #5 2007-07-18/20 SCC, Ottawa, Canada OWGV #6 2007-10-1/3 Kona, Hawaii, USA OWGV #7 2007-12 (during week of 10 - 14) SEI,Pittsburgh, PA, USA 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 31

OWG:Vulnerability ProductA type 3 Technical Report A document containing information of a different kind from that whichis normally published as an International StandardScope: The TR describes a set of common mode failures that occur acrossa variety of languages. The document will not contain normative statements, but informationand suggestions.No single programming language or family of programminglanguages is to be singled out As many programming languages as possible should be involved Need not be just the languages defined by ISO Standards 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 32

Dual Approach to Identifying VulnerabilitiesEmpirical approach: Observe the vulnerabilities thatoccur in the wild and describe them, e.g. bufferoverrun, execution of unvalidated remote contentAnalytical approach: Identify potential vulnerabilitiesthrough analysis of programming languagesThe second approach may help usidentify tomorrow’s vulnerabilities. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 33

Analytical ApproachVulnerabilities occur when software behaves in a manner thatwas not predicted by a competent developer. Sources of suchvulnerabilities include: Issues arising from lack of knowledge—Complex language features or interactions of features that may bemisunderstood—Portions of the language left unspecified by the standard—Portions of the language that are implementation-defined—Portions of the language that are specified as undefined Issues arising from human cognitive limitations, i.e, exceeding thehuman ability to understand Issues arising from non-standard extensions of languages 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 34

Language-Independent Vulnerability Description Example 16.1 SM-004 Out of bounds array element access6.1.1 Description of application vulnerabilityUnpredictable behaviour can occur when accessing the elements of an arrayoutside the bounds of the array.6.1.2 Cross referenceCWE: 1296.1.3 CategorizationSection 5.1.26.1.4 Mechanism of failureArrays are defined, perhaps statically, perhaps dynamically, to have given bounds. In order to access an element of the array, index values for one ormore dimensions of the array must be computed. If the index values do not fall within the defined bounds of the array, then access might occur to thewrong element of the array, or access might occur to storage that is outside the array. A write to a location outside the array may change the value ofother data variables or may even change program code.6.1.5 Possible ways to avoid the failureThe vulnerability can be avoided by not using arrays, by using whole array operations, by checking and preventing access beyond the bounds of thearray, or by catching erroneous accesses when they occur. The compiler might generate appropriate code, the run-time system might perform checking,or the programmer might explicitly code appropriate checks. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 35

Language-Independent Vulnerability Description Example 26.1.6 Assumed variations among languagesThis vulnerability description is intended to be applicable to languages with thefollowing characteristics: The size and bounds of arrays and their extents might be statically determinable or dynamic. Some languages provide both capabilities.Language implementations might or might not statically detect out of boundaccess and generate a compile-time diagnostic. At run-time the implementation might or might not detect the out of bounds access and provide a notification at run-time. The notificationmight be treatable by the program or it might not be. Accesses might violate the bounds of the entire array or violate the bounds of a particular extent. It is possible that the former is checkedand detected by the implementation while the latter is not. The information needed to detect the violation might or might not be available depending on the context of use. (For example, passing anarray to a subroutine via a pointer might deprive the subroutine of information regarding the size of the array.) Some languages provide for whole array operations that may obviate theneed to access individual elements.Some languages may automatically extend the bounds of an array to accommodate accesses that might otherwise have been beyond thebounds. (This may or may not match the programmer's intent.) 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 36

Language-Independent Vulnerability Description Example 36.1.7 Avoiding the vulnerability or mitigating its effectsSoftware developers can avoid the vulnerability or mitigate its ill effects in thefollowing ways: If possible, utilize language features for whole array operations that obviate the need to access individualelements. If possible, utilize language features for matching the range of the index variable to the dimension of the array. If the compiler can verify correct usage, then no mitigation is required beyond performing the verification. If the run-time system can check the validity of the access, then appropriate action maydepend upon the usage of the system (e.g. continuing degraded operation in a safety-critical system versus immediate termination of asecure system). Otherwise, it is the responsibility of the programmer:—to use index variables that can be shown to be constrained within the extent of the array;—to explicitly check the values of indexes to ensure that they fall within the bounds of the corresponding dimension of the array;—to use library routines that obviate the need to access individual elements; or—to provide some other means of assurance that arrays will not be accessed beyond their bounds. Those other means of assurancemight include proofs of correctness, analysis with tools, verification techniques, etc. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 37

Desired OutcomesProvide guidance to users of programminglanguages that : Assists them in improving the predictability of theexecution of their software even in the presence of anattacker Informs their selection of an appropriate programminglanguage for their jobProvide feedback to language standardizers,resulting in the improvement of programminglanguage standards. 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 38

For More InformationVisit web c.aitcnet.org/isai/Contact presenters:Robert C. Seacordrcs@cert.orgJames Mooremoorej@mitre.org 2007 The MITRE Corporation and CarnegieMellon University. All rights reserved.Moore and Seacord,SSTC 2007 - 39

CERT Secure Coding Standards Identify coding practices that can be used to improve the security of software systems under development Coding practices are classified as either rules or recommendations Rules need to be followed to claim compliance . Recommendations are guidelines or suggestions . Development of Secure Coding Standards is a