WIXLIB

Secure CodingStandards2008 February 5thR b tCRobertC. SSeacordd 2009 Carnegie Mellon University

AgendagSoftware SecurityyCERT Secure Coding InitiativeCERT Secure Coding StandardsFuture Directions and Key Points2

Increasingg VulnerabilitiesReactingg to vulnerabilities inexisting systems is not working3

ApplicationppSecurityy4

Most Vulnerabilities caused byProgramming ErrorsAccording to a study of vulnerabilities in the NationalVulnerabilty Database (NVD) in 2004 by Heffley/Meunier: 64% of the vulnerabilities are due to programming errors 36% of vulnerabilities are due to configuration or design problems.Most of these pprogramminggg errors are repeatedpbasicmistakes. 20% buffer overflows 11% directory traversal attacks 9% format stringg vulnerabilities 4% symlink attacks 4% cross-site scriptingp g vulnerabilities3% shell metacharacter 5

AgendagSoftware SecurityyCERT Secure Coding InitiativeCERT Secure Coding StandardsFuture Directions and Key Points6

Secure Codingg InitiativeInitiative GoalsCurrent CapabilitiesWork with software developers andsoftware development organizationsto eliminate vulnerabilities resultingfrom coding errors before they aredeployed.Secure coding standardswww.securecoding.cert.orgSource code analysis andcertificationTraining coursesInvolved in international standardsdevelopment.Overall ThrustsAdvance the state of the practice insecure codingdiIdentify common programmingerrors that lead to softwarevulnerabilitiesEstablishstab s stastandardda d secusecuree codcodinggpracticesEducate software developers7

EXPLORECREATEAPPLYAMPLIFYSUSTAINCERT C Secure Coding Standard Open Group Adoption WG23 Language Annex Software Certification Wiki content Tool CertificationCERT C Secure Coding StandardThe CERT Sun Microsystems Secure Coding Standard for JavaC Language Security Annex and Prototype8

C Languageg g Securityy Annex and PrototypeypC language standard is undergoing a major revision “C1X” Originally about security, emphasis has shifted 180 degrees towardssupport for multithreading and performance optimizations that may actuallyhurt security.This work would develop a An informative “Analyzability”yy annex to the C standard that defines asecurity “profile”— some enhancements would be implemented by simply recompiling— others may require source code modificationa prototype implementation using gccAnnex could be implemented by compiler vendors who want to provide a secure implementation do not have to compete head to head with other compilers only concernedwith performance.9

C Languageg g Securityy Annex and PrototypeypThis project could have a greater positive impact on softwaresecurity than anything I can imagine given that success of the C securityy annex would motivate C vendors to provide the same semantics for C C and C account for 26%26% of the market (according tothe TIOBE index) 65% of vulnerabilities in the USUS-CERTCERT vulnerabilitydatabase involve these languages standardizationt d di ti willill resultlt ini bbroadd adoptiond ti bby compilerilvendors10

AgendagSoftware SecurityyCERT Secure Coding InitiativeCERT Secure Coding StandardsFuture Directions and Key Points11

CERT Secure Codingg 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 effort12

ScopepThe 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: Cpprogramminggg languageg g ((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.13

Secure Codingg Wikiwww.securecoding.cert.orgRules are solicited from thecommunityPublished as candidate rulesandd recommendationsd tion thethCERT Wiki.Threaded discussions usedfor public vettingCandidate coding practices aremoved into a secure codinggstandard when consensus isreached14

RulesCodinggppractices are defined as rules when1.Violation of the coding practice is likely to result ina security flaw that may result in an exploitablevulnerability.2.There is a denumerable set of conditions forwhich violating the coding practice is necessary toensure correct behavior.3.ConformanceCftot theth codingdi practiceti can bbedetermined through automated analysis, formalmethods, or manual inspection techniques.15

RecommendationsCodinggppractices are defined as recommendationswhen11.Application of the coding practice is likely toimprove system security.2.One or more of the requirements necessary for acodinggppractice to be considered a rule cannot bemet.16

The CERT C Secure Codingg StandardDevelopedp with communityyinvolvement, including over320 registered participantson the wiki.Version 1.0 published byAddison-Wesley inSeptember, 2008. 134 Recommendations 89 Rules17

Noncompliant Examples & Compliant SolutionsNoncompliant Code ExampleIn this noncompliant code example, the char pointer p isg literal. Attemptingp g to modifyyinitialized to the address of a stringthe string literal results in undefined behavior.char *pp "stringstring literal";literal ; p[0] 'S';S ;Compliant SolutionA an array initializer,Asi iti lia stringt i litliterall specifiesifi theth initiali iti l valueslof characters in an array as well as the size of the array. Thiscoded createst a copy off theth stringt i literallit l ini theth space allocatedllt dto the character array a. The string stored in a can be safelymodified.modifiedchar a[] "string literal"; a[0] 'S';18

Distribution of C Recommendations0510Preprocessor (PRE)1511Declarations and Initialization (DCL)16Expressions (EXP)13Integers (INT)16Fl ti PointFloatingP i t (FLP)Arrays (ARR)2043Characters and Strings (STR)9Memory Management (MEM)11Input Output (FIO)17Environment (ENV)Signals (SIG)53Error Handling (ERR)7Miscellaneous (MSC)POSIX (POS)16319

Distribution of C Rules0Preprocessor (PRE)246810167Expressions (EXP)9Integers (INT)6Floating Point (FLP)5Arrays (ARR)9Characters and Strings (STR)8Memoryy Managementg((MEM))6Input Output (FIO)15Environment (ENV)4SiSignalsl (SIG)5Error Handling (ERR)POSIX (POS)142Declarations and Initialization (DCL)Miscellaneous (MSC)1232820

POSIXMany of the core guidelines demonstrate compliant solutionsthat rely for POSIX-compliant systems.g Standard also contains anThe CERT C Secure Codingappendix with guidelines (3 recommendations and 8 rules) forusingg functions that are defined as ppart of the POSIX familyy ofstandards but are not included in ISO/IEC 9899-1999.These rules and recommendations are not part of the corestandard because they do not apply in all C languageapplicationsppand because theyy representpan incompletepset.The intent of providing these guidelines is to demonstrate howrules and recommendations for other standards or specificimplementations may be integrated with the core C99recommendations.21

Contributors and ReviewersContributorsA b b Ahmad,ArbobAh d JJuan AlAlvarado,d DDave AAronson, AbhishekAbhi h k Arya,ABJ Bayha,B h LeviL iBBroderick,d i k HHallBurch, Steven Christey, Ciera Christopher, Geoff Clare, Joe Damato, Stephen C. Dewhurst,Susan Ditmore, Chad Dougherty, Mark Dowd, Xiaoyi Fei, William Fithen, Hallvard Furuseth,Jeffrey Gennari,Gennari Douglas A.A Gwyn,Gwyn Shaun HedrickHedrick, Christina Johns,Johns David Keaton,Keaton TakuyaKondo, Masaki Kubo, Richard Lane, Stephanie Wan-Ruey Lee, Jonathan Leffler, Fred Long,Gregory K. Look, Nat Lyle, Larry Maccherone, John McDonald, Dhruv Mohindra, BhaswanthNalabothula Justin Pincar,Nalabothula,Pincar Randy MeyersMeyers, David M.M Pickett,Pickett Thomas Plum,Plum Dan Saks,Saks RobertC. Seacord, David Svoboda, Chris Taschner, Ben Tucker, Fred J. Tydeman, Nick Stoughton,Wietse Venema, Alex Volkovitsky, Grant Watters, and Gary Yuan.ReviewersKevin Bagust, Greg Beeley, Arjun Bijanki, John Bode, Stewart Brodie, G Bulmer, Kyle Comer,Sean Connelly, Ale Contenti, Tom Danielsen, Török Edwin, Brian Ewins, Justin Ferguson,St h Friedl,StephenF i dl SamiumS iGGromoff,ff KowsikKik Guruswamy,GP t Gutmann,PeterG tRi h d Heathfield,RichardH thfi ldDarryl Hill, Paul Hsieh, Ivan Jager, Steven G. Johnson, Anders Kaseorg, Jerry Leichter,Nicholas Marriott, Scott Meyers, Eric Miller, Ron Natalie, Heikki Orsila, Dan Plakosh, P.J.Plauger Michel Schinz,Plauger,Schinz Eric Sosman,Sosman Chris Tapp,Tapp Andrey Tarasevich,Tarasevich Josh TriplettTriplett, PavelVasilyev, Ivan Vecerina, Zeljko Vrba, David Wagner, Henry S. Warren, Colin Watson, ZhenyuWu, Drew Yao, and Christopher Yeleighton.22

Priorities and LevelsHigh severityseverity,likely,inexpensive torepairi flflawsL1 P12-P27L2 P6-P9L3 P1-P4Med severity,probable, medcost to repairflawsLow severity,unlikelyunlikely,expensive torepair flaws23

FIO30-C. Exclude user input from format stringsg24

CERT MitigationgInformationVulnerabilityu e ab ty Noteote VU#649732U#6 9 3This vulnerability occurred as aresult of failing to comply with ruleFIO30-C of the CERT CProgramming Language SecureCoding StandardStandard.CERT Secure Coding StandardUS CERT Technical AlertsExamples of vulnerabilitiesresulting from the violationof this recommendation canbe found on the CERTwebsite .25

Secure Codingg Standard ApplicationsppEstablish secure codinggppractices within anorganization may be extended with organizationorganization-specificspecific rules cannot replace or remove existing rulesTrain software professionalsCertify programmers in securecodingEstablish requirements forytoolssoftware analysisSoftware Certification26

Major Software Vendor LDRA AdoptsCERT C Secure Coding StandardLDRA shipsp new TBsecure completepwithCERT C Secure Coding programming checkerScreenshot from the LDRA tool suite shows the selection of the CERT C secure coding standard from the C standards models27

LDRA Press ReleaseBoston,, MA – October 26,, 2008. LDRA (Booth(1017), provider of the most complete automatedsoftware verification,verification source code analysis and testtools covering the full development lifecycle, hasreleased its new TBsecure plug-inplug in complete with theCarnegie Mellon Software Engineering Institute (SEI)CERT C secure codingdi standard.t d dTBsecure identifies security vulnerabilities andenables implementation of the just released CERT CSecure Coding Standard version 11.0.028

Software Validation & VerificationImplementingpg checkers for various software analysisytools to verify compliance with CERT secure codingstandards LDRA Fortify SCA Lawrence Livermore National Laboratory (LLNL)Compass / ROSE Coverityy Prevent29

CMU/SEI-2008-TR-014“Evaluation of CERT Secure Coding Rules through Integrationwith Source Code Analysis Tools”y to evaluate the effectiveness of secure codinggppractices,,Studyincluding the use of static analysis tools coupled with securecodingg rule sets the CERT C Programming Language Secure Coding Standard CERT C Programminggg Languageg g Secure Codingg StandardThis study was a joint effort between the CERT Secure CodingInitiative and JPCERT/CC.The objectives of the study were to evaluate the efficacy of theCERT Secure Coding Standards and source code analysistools in improving the quality and security of commercialsoftware projects.projects30