MISRA C - Safety v Security Fifth VDA Automotive SYS Conference - PowerPoint PPT Presentation

MISRA C - Safety v Security Fifth VDA Automotive SYS Conference Andrew Banks BSc IEng MIET FBCS CITP Frazer-Nash Research Limited, and Chairman, MISRA C Working Group

MISRA C A Quick History 2 July 14, 2015

MISRA-C – The Rationale Despite 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 checking MISRA C is one solution... 3 July 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 ) “Guidelines for the use of the C language in critical systems” - - Adds compatibility with ISO/IEC 9899:1999 (aka C99 ) 4 July 14, 2015

MISRA-C – The 2012 Edition Published early 2013 159 Guidelines in total - 16 Directives o 9 Required o 7 Advisory - 143 Rules o 10 Mandatory o 101 Required o 32 Advisory A compliance and deviation policy 5 July 14, 2015

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

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

MISRA C Misunderstandings 8 July 14, 2015

Myth Busting #1 The Misunderstanding - MISRA C is only applicable to the automotive industry The History - MISRA C was originated by the automotive industry, for the automotive industry... 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_C.pdf • http://www.stroustrup.com/JSF-AV-rules.pdf 9 July 14, 2015

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

ESCAR 2014, Hamburg 11 July 14, 2015

MISRA C Directives Guidelines that are not Rules! 12 July 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 full description necessary to perform a check for compliance. - Additional information, such as might be provided in design documents or requirement specifications, is required in order to be able to perform the check. - Static analysis tools may be able to assist in checking compliance with directives , but different tools may place different interpretations on what constitutes non-compliance. Note: Compliance is still required – just as for the rules! 13 July 14, 2015

MISRA C Directives – Directive 4.1 From the MISRA C:2012 headline - Run-time failures shall be minimized Rationale - The C language was designed to provide very limited built-in run-time checking. 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 for errors to occur Problem areas - arithmetic errors, array bound errors, function parameters, pointer arithmetic/de-referencing 14 July 14, 2015

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

Safety v Security Comparison with other guidelines 16 July 14, 2015

ISO/IEC TS 17961 C Secure Coding Rules 17 July 14, 2015

ISO/IEC TS 17961 – C Secure Coding Rules Produced by ISO/IEC JTC 1/SC 22/WG 14 – the same people responsible for the C standard itself Originally proposed to be based on CERT-C (see later) but significantly rationalised From the document’s Background: “In practice, security-critical and safety-critical code have the same - requirements” “ The purpose of this Technical Specification is to specify analyzable - secure coding rules that can be automatically enforced to detect security flaws in C-conforming applications” 18 July 14, 2015

ISO/IEC TS 17961 – C Secure Coding Coverage Coverage Method # Comments MISRA covers fully – explicitly 22 Some rules are stricter than SecureC MISRA covers fully – broad 11 Eg: bans dynamic memory, signal.h 6 Undefined/unspecified behaviour MISRA covers fully – implicitly 3 Standard library MISRA covers partially – broad 2 MISRA does not cover directly 2 46 19 July 14, 2015

ISO/IEC TS 17961 – The Gaps The 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 parameter 1 rule - Comparisons of padding data 1 rule Proposal - MISRA C:2012 be enhanced to address these gaps 20 July 14, 2015

The Gaps – Taintedness C 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 rules o General prohibition in the use of stdio.h, signal.h etc Proposed way ahead - Add a new MISRA C directive to require validation of externally sourced data to protect against taintedness. - Additional explicit rules may be added as required. 21 July 14, 2015

The Gaps – Use of stdlib.h environment functions C Secure - Rule 5.29 and Rule 5.42 MISRA C:2012 - Rule R21.8 prohibits the use of getenv() but does not mention the use of localeconv() , setlocale() and strerror() Ideal Solution - Ideally, the C Standard should defines these functions as returning const char * rather than straight char * - Note: additional thread-safe functions added in C11 Proposed 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() 22 July 14, 2015

The Gaps – Use of sizeof() on a pointer parameter C Secure - Rule 5.38 MISRA 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. 23 July 14, 2015

The Gaps – Comparison of padding data C Secure - Rule 5.9 MISRA 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() with structures or unions. - Add appropriate MISRA C rule(s) to prevent use of memcmp() with character strings – use strcmp() or strncmp() instead. 24 July 14, 2015

ISO/IEC TS 17961 – The Broad Approaches Some C Secure rules are implicitly fully covered by broad approaches - MISRA C:2012 prohibits the use of the restrict keyword 1 rule - MISRA C:2012 prohibits the use of dynamic memory allocation 3 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 rules o The use of string formatting functions o The use of EOF Proposal - Keep these broad approaches under review - Establish more targeted rules where appropriate 25 July 14, 2015

The Broad – string formatting functions C Secure - Rule 5.24 and Rule 5.45 MISRA 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 apply Possible 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.6 26 July 14, 2015