MISRA C - Safety V Security - Andrew Banks

2y ago
37 Views
3 Downloads
651.31 KB
44 Pages
Last View : 16d ago
Last Download : 2m ago
Upload by : Dani Mulvey
Transcription

MISRA C - Safety v SecurityFifth VDA Automotive SYS ConferenceAndrew BanksBSc IEng MIET FBCS CITPFrazer-Nash Research Limited, andChairman, MISRA C Working Group

MISRA CA Quick History2July 14, 2015

MISRA-C – The RationaleDespite its popularity, there are several drawbacks with the C language, eg: The ISO Standard language definition is incomplete Behaviour that is Undefined Behaviour that is Unspecified Behaviour that is Implementation Defined Language misuse and obfuscation Language misunderstanding Run-time error checkingMISRA C is one solution.3July 14, 2015

MISRA-C – A Quick HistoryMISRA-C:1998 (aka MISRA-C1)- “Guidelines for the use of the C language in vehicle based software”- Compatible with ISO/IEC 9899:1990 (aka C90)MISRA-C:2004 (aka MISRA-C2)- “Guidelines for the use of the C language in critical systems”- Remains compatible with ISO/IEC 9899:1990 (aka C90)MISRA C:2012 (aka MISRA-C3)- “Guidelines for the use of the C language in critical systems”- Adds compatibility with ISO/IEC 9899:1999 (aka C99)4July 14, 2015

MISRA-C – The 2012 EditionPublished early 2013159 Guidelines in total- 16 Directiveso 9 Requiredo 7 Advisory- 143 Ruleso 10 Mandatoryo 101 Requiredo 32 AdvisoryA compliance and deviation policy5July 14, 2015

MISRA-C – The VisionThe vision of MISRA C is set out in the opening paragraph of theGuidelines:The MISRA C Guidelines define a subset of the C language in whichthe opportunity to make mistakes is either removed or reduced.Many standards for the development of safety-related softwarerequire, or recommend, the use of a language subset, and this canalso be used to develop any application with high integrity or highreliability requirements.6July 14, 2015

MISRA-C – Work In ProgressMISRA C:2012 Technical Corrigendum 1- Address typographical and clarificationMISRA Compliance- Enhances guidance for compliance guidance- Clarifies/tightens the Deviation process- Standalone documento Compatible with MISRA C:2012 (and any future versions)o Compatible with MISRA C :20xxo No reason it cannot be applied to earlier versions of either document!And a few other things.- Looking at C11 amongst them7July 14, 2015

MISRA CMisunderstandings8July 14, 2015

Myth Busting #1The Misunderstanding- MISRA C is only applicable to the automotive industryThe History- MISRA C was originated by the automotive industry, for the automotiveindustry. and we are proud of our automotive heritage.The Reality- MISRA C is applicable to any industry that requires high-integrity software- MISRA C has been adopted by many industries, including medical, rail,aerospace, space and defence. eg: http://lars-lab.jpl.nasa.gov/JPL Coding Standard ly 14, 2015

Myth Busting #2The Misunderstanding- MISRA C is only a safety coding standard, not a secure/security oneThe History- MISRA C suggests (in its vision) its use in safety-related softwareThe Reality- MISRA C also suggests (in its vision) its applicability to any applicationwith high integrity or high reliability requirements- The difference between safety and security are largely semantic- Unfortunately, a perception remains.10July 14, 2015

ESCAR 2014, Hamburg11July 14, 2015

MISRA C DirectivesGuidelines that are not Rules!12July 14, 2015

MISRA C Directives – What is a Directive?From the MISRA C:2012- A directive is a guideline for which it is not possible to provide the fulldescription necessary to perform a check for compliance.- Additional information, such as might be provided in design documents orrequirement specifications, is required in order to be able to perform thecheck.- Static analysis tools may be able to assist in checking compliance withdirectives, but different tools may place different interpretations on whatconstitutes non-compliance.Note: Compliance is still required – just as for the rules!13July 14, 2015

MISRA C Directives – Directive 4.1From the MISRA C:2012 headline- Run-time failures shall be minimizedRationale- The C language was designed to provide very limited built-in run-timechecking. This places the burden on the programmer.What does this mean?- Techniques to avoid run-time failures should be planned and documented,for example in design standards, test plans and code review checklists.- Dynamic checks should be added where-ever there is a potential forerrors to occurProblem areas- arithmetic errors, array bound errors, function parameters, pointerarithmetic/de-referencing14July 14, 2015

MISRA C Directives – Directive 4.11From the MISRA C:2012 headline- The validity of values passed to library functions shall be checkedRationale- The C standard does not require the standard library to check the validityof parameters passed to them.What does this mean?- Dynamic checks should be added where-ever there is a potential forerrors to occurProblem areas- Libraries ctype.h math.h and string.h (and others!)15July 14, 2015

Safety v SecurityComparison with other guidelines16July 14, 2015

ISO/IEC TS 17961C Secure Coding Rules17July 14, 2015

ISO/IEC TS 17961 – C Secure Coding RulesProduced by ISO/IEC JTC 1/SC 22/WG 14 – the same people responsible forthe C standard itselfOriginally proposed to be based on CERT-C (see later) but significantlyrationalisedFrom the document’s Background:- “In practice, security-critical and safety-critical code have the samerequirements”- “The purpose of this Technical Specification is to specify analyzablesecure coding rules that can be automatically enforced to detect securityflaws in C-conforming applications”18July 14, 2015

ISO/IEC TS 17961 – C Secure Coding CoverageCoverage Method#MISRA covers fully – explicitly22 Some rules are stricter than SecureCMISRA covers fully – broad11 Eg: bans dynamic memory, signal.hMISRA covers fully – implicitlyComments6Undefined/unspecified behaviour3Standard libraryMISRA covers partially – broad2MISRA does not cover directly24619July 14, 2015

ISO/IEC TS 17961 – The GapsThe gaps (partial or not covered) can be grouped as follows:- Taintedness as a concept- The use of getenv(), localeconv(), setlocale() and strerror()2 rules- Use of sizeof() on a pointer function parameter1 rule- Comparisons of padding data1 ruleProposal- MISRA C:2012 be enhanced to address these gaps20July 14, 2015

The Gaps – TaintednessC Secure- Many!MISRA C:2012- No explicit coverage of taintedness- Directives D4.1 and D4.11 cover many of the consequences.- Some undefined behaviour also trapped by R1.3- Some unwanted behaviour also trapped by broad ruleso General prohibition in the use of stdio.h, signal.h etcProposed way ahead- Add a new MISRA C directive to require validation of externally sourceddata to protect against taintedness.- Additional explicit rules may be added as required.21July 14, 2015

The Gaps – Use of stdlib.h environment functionsC Secure- Rule 5.29 and Rule 5.42MISRA C:2012- Rule R21.8 prohibits the use of getenv() but does not mention the use oflocaleconv(), setlocale() and strerror()Ideal Solution- Ideally, the C Standard should defines these functions as returningconst char * rather than straight char *- Note: additional thread-safe functions added in C11Proposed way ahead- Permit use of getenv(); Add MISRA C rule(s) to enforce read-only nature,and to prevent wrong data being used after multiple calls.- Also applies to asctime() and ctime()22July 14, 2015

The Gaps – Use of sizeof() on a pointer parameterC Secure- Rule 5.38MISRA C:2012- No explicit coverage- Could tenuously claim D4.1 and D4.11 covers, but.Proposed way ahead- Add an appropriate MISRA C rule to detect this.23July 14, 2015

The Gaps – Comparison of padding dataC Secure- Rule 5.9MISRA C:2012- No explicit coverage- Could tenuously claim D4.1 and D4.11 covers, but.Proposed way ahead- Add appropriate MISRA C rule(s) to prevent use of memcmp() withstructures or unions.- Add appropriate MISRA C rule(s) to prevent use of memcmp() withcharacter strings – use strcmp() or strncmp() instead.24July 14, 2015

ISO/IEC TS 17961 – The Broad ApproachesSome C Secure rules are implicitly fully covered by broad approaches- MISRA C:2012 prohibits the use of the restrict keyword1 rule- MISRA C:2012 prohibits the use of dynamic memory allocation3 rules- MISRA C:2012 prohibits the use of the features in signal.h 3 rules- MISRA C:2012 prohibits the use of the features in stdio.h 4 ruleso The use of string formatting functionso The use of EOFProposal- Keep these broad approaches under review- Establish more targeted rules where appropriate25July 14, 2015

The Broad – string formatting functionsC Secure- Rule 5.24 and Rule 5.45MISRA C:2012- Use of stdio.h generally prohibited by Advisory R21.6- Some undefined behaviour generally trapped by R1.3- Directives D4.1 and D4.11 also applyPossible way ahead- No change – exiting undefined behaviour is caught- Add catchall taint directive?- Add explicit MISRA C rule(s)- Avoid interaction by existing Rule R21.626July 14, 2015

The Broad – The use of EOFC Secure- Rule 5.16 and Rule 5.43MISRA C:2012- Use of stdio.h generally prohibited by Advisory R21.6- Directives D4.1 and D4.11 applyIdeal Solution- Ideally, the C Standard should be fixed. But given the response, when thiswas raised at the C99 CD2 ballot, that is not likely to happen!“Has been like this for at least 10 years, no need to change. Alreadyknown problem with too much existing practice.”Possible way ahead- Add appropriate MISRA C rule(s) to protect against tainted values aroundEOF27July 14, 2015

ISO/IEC TS 17961 – The Implicit?Many of the Secure C rules are implicitly covered by Directives- D4.1 Run-time failures shall be minimised- D4.11 The validity of values passed to library functions shall be checkedSome of these may benefit from additional, focussed, rules- The use of errno1 rule- The use of character handling functions1 rules- Use of string copying functions1 rule28July 14, 2015

The Implicit – Use of errnoC Secure- Rule 5.25MISRA C:2012- No explicit coverage. permitted without restrictions- Directive D1.1 mentions errno in passing- Directives D4.1, D4.11 and D4.7 all apply- Note: MISRA C:2004 and earlier simply banned the use of errnoPossible way ahead- Add appropriate MISRA C rules to protect against tainted values andinappropriate use.29July 14, 2015

The Implicit – string copying functionsC Secure- Rule 5.37MISRA C:2012- No explicit coverage.- Directives D4.1 and D4.11 do applyPossible way ahead- Add explicit MISRA C rule(s)- Also applies to strncpy and strncat()30July 14, 2015

ISO/IEC TS 17961 – Revised C Secure CoverageCoverage Method#MISRA covers fully – explicitly31MISRA covers fully – broad approach7Eg: bans dynamic memory, signals3Taint5Undefined/unspecified behaviourMISRA covers fully – implicitlyMISRA covers partially or not at allComments04631July 14, 2015

ISO/IEC TS 17961 – The Next StepsProposed Next Steps- MISRA C Working Group will finalise deliberations- Update to existing MISRA C:2012 document to be issuedo Target late 2015 or early 2016 (TBC)o Timeline to coincide with release of Technical Corrigendum 1o Propose to be issued as Amendment 1- Update will include a coverage matrix against ISO/IEC TS 1976132July 14, 2015

CERT-CC Secure Coding Rules33July 14, 2015

CERT-C – Secure Coding StandardWhat is CERT-C- Produced by the Software Engineering Institute (SEI) at Carnegie MellonUniversity.- Sponsored by the U.S. Department of Defense- Originally proposed to be adopted as an ISO standard, but this was notprogressed by WG14, who progressed ISO/IEC TS 17961 instead.The MISRA C Position- We view CERT-C as complementary to MISRA Co Most rules align with the MISRA C ruleso Some small variance due to difference of focus (not just safety v security)- We are reviewing CERT-C’s rules and recommendations34July 14, 2015

CERT-C (April 2014) – MISRA C:2012 CoverageCoverage Method#1#2 CommentsMISRA covers – fully3642MISRA covers – partially1822MISRA does not cover explicitly4133 But many are covered by directivesPossible Contradictions!119698#1Assessment presented at escrypt.#2MISRA C Working Group assessment(MISRA C:2012 against CERT-C:Apr14)35July 14, 2015

CERT-C v MISRA C:2012 Contradiction?Array bound specification on initialization with string literals- CERT-C Rule STR11-Co Do not specify the bound of a character array initialised with a string literal- MISRA C:2012 rule R9.5 (Required)o Where designated initializers are used to initialise an array object, the size ofthe array shall be specified explicitly.Example Cited- char test[] { [0] “abc” }; // Compliant to CERT-C but not MISRA C// . null-terminated string of three characters- char test[3] { [0] “abc” }; // Compliant to MISRA C but not CERT-C// . probably wrong size of array lengthNote: MISRA C rule R9.5 only applies to Designated Initializers36July 14, 2015

CERT-C v MISRA C:2012 Contradiction?Alternative example #1- char test[] { [0] “a” };- char test[10] { [0] “a” };// Compliant to CERT-C but not MISRA C// . but really only a single character array?// Compliant to MISRA C but not CERT-C// . we really wanted 10 charactersAlternative example #2- char test[] { [0] “abc” };// Compliant to CERT-C but not MISRA C// . how big should that array be?- char test[4] { [0] “abc” };// Compliant to MISRA C but not CERT-C// . three characters plus null-terminator- char test[3] { [0] “abc” };// Compliant to MISRA C but not CERT-CC// . three characters without null-terminator- char test[3] { [0] “abcd” }; // Constraint error37July 14, 2015

CERT-C v MISRA C:2012 Contradiction?Let me repeat: MISRA C:2012 rule R9.5 only applies to Designated InitializersCompare with advisory MISRA C:2012 rule R8.11- The rule Headline seems to maintain the contradiction:o When an array with external linkage is declared, its size should be explicitlyspecified.- And the rule Rationale explains whyo Providing size information for each declaration permits them to be checked forconsistency. It may also permit a static checker to perform some array boundsanalysis without needing to analyse more than one translation unit.- But the rule Amplification contains the following clarification:o It is possible to define an array and specify its size implicitly by means ofinitialization.No other MISRA C:2012 rule requires the array size to be explicitly specified.38July 14, 2015

In Summary39July 14, 2015

MISRA C – In SummaryMISRA C is- widely respected as a safety-related coding standard- equally applicable as a security-related coding standardProposed Way Ahead- Address the gaps between MISRA C:2012 and ISO/IEC TS 17961:2013- The MISRA C Working Group will continue the review activity againsto CERT-Co Common Weakness Enumerationo . and any other sources that may become known- The MISRA C Working Group welcomes feedback from users40July 14, 2015

Any Questions?41July 14, 2015

Danke SchönThank You!I would like to acknowledge the support of the members of the MISRA C Working Group for theirassistance in preparing this presentation.42July 14, 2015

ReferencesMISRA C:2012http://misra.org.uk/Embedded Security in Cars (November 2014, .htmlISO/IEC TS 17961:2013 – C secure coding ruleshttp://www.iso.org/iso/catalogue detail.htm?csnumber C 9899 CD2 comments and g14/www/docs/n872.htm43July 14, 2015

About the speakerBiography- Chairman of MISRA-C since June 2013- Over 25 years experience in developing real-timeembedded software systems, across a number ofindustries- Chartered Fellow of the British Computer Society- Member of the Institution of Engineering & TechnologySocial om/in/AndrewBanks44July 14, 2015

MISRA-C – A Quick History MISRA-C:1998 (aka MISRA-C1) -“Guidelines for the use of the C language in vehicle based software”-Compatible with ISO/IEC 9899:1990 (aka C90) MISRA-C:2004 (aka MISRA-C2) -“Guidelines for the use of the C language in critical systems”-Remains compatible with ISO/IEC 9899:1990 (aka C90) MISRA C:2012 (aka MISRA-C3) -“Guid

Related Documents:

an update, MISRA-C:2004 (this document), which improves on, and corrects the issues faced by software engineers implementing MISRA-C:1998. While producing MISRA-C:2004, the question of addressing the 1999 C standard [8] arose. At this time, only issues with MISRA-C:1998 are addressed due to the limited support for C99 on embedded microprocessors.File Size: 1MBPage Count: 116Explore further(PDF) MISRA C:2 012 Guidelines for the use of the C .www.academia.eduMISRA-C Guidelines for Safety Critical Softwarebarrgroup.comMISRA C:2004 and MISRA AC AGC Coding Rules - MATLAB & Simulinkwww.mathworks.comMISRA C and MISRA C — Coding Standards For Compliance .www.perforce.comMISRA-C:2012 Standards Model Summary for C / C my.ldrasoftware.co.ukRecommended to you b

The [MISRA-C:2004] guidelines place great emphasis on the use of static code analysts tools to check compliance with the MISRA-C language subset. In fact, the automatic enforcement of as many rules as possible is mandated by MISRA-C:2004 required rule 21.1. NOTE: The completely automatic enf

The [MISRA-C:2004] guidelines place great emphasis on the use of static code analysts tools to check compliance with the MISRA-C language subset. In fact, the automatic enforcement of as many rules as possible is mandated by MISRA-C:2004 required rule 21.1. NOTE: The completely automatic enforcement of 100% of the MI

In the MISRA C:2012 and MISRA C:2012 A1 suites, there is also a sub-suite specifically for C99. (Note: MISRA C:2004 does not support C99.) They contain the tests that are compliant to the respective version of the C standard. Test

CMSIS code base is MISRA-C 2004 compliant, which implies that every extension should be compliant, too. MISRA-C is a set of safety rules established by the “Motor Industry Software Reliability Association” for the C programming language. Maintaining MISRA compliance can be trick

Abassi RTOS MISRA-C:2004 Compliance Report 2012.04.30 Rev 1.1 Page 5 1 Introduction This document is a report on the compliance of the Abassi RTOS to the MISRA-C:2004 coding standard. The first section describes the techniques used to verify th

MISRA C:2004 As MISRA C became widely adopted, areas were identified where it needed to be improved and clarified. A new version was published in 2004. It was structured rather differently and contained a few additional rules but

AutoCAD Architecture) is now included with AutoCAD as a specialized toolset. It is built specifically to create and modify software-based design and documentation productivity for architects. Purpose-built architectural design tools help eliminate errors and provide accurate information to the user, allowing more time for architectural design. This study details the productivity gains that .