MISRA C Presentation to IPA/SEC

Transcription

1 MISRA C Presentation to IPA/SEC Safety and Security... and future plans for MISRA C Andrew Banks BSc IEng MIET FBCS CITP Frazer-Nash Research Limited, and Chairman, MISRA C Working Group

2 MISRA C A Quick History 2

3 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

4 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

5 MISRA-C The 2012 Edition Published early Guidelines in total - 16 Directives o 9 Required o 7 Advisory Rules o 10 Mandatory o 101 Required o 32 Advisory Includes a compliance and deviation policy 5

6 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

7 MISRA-C Work In Progress MISRA C:2012 Technical Corrigendum 1 - Address typographical errors and guideline 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... - Security - C11 (etc) 7

8 MISRA C Directives Guidelines that are not Rules! 8

9 MISRA C Directives What is a Directive? From the MISRA C: 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! 9

10 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 10

11 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!) 11

12 Standard Conformance Freestanding v Hosted 12

13 Strict Conformance Chapter 4 of the ISO Standard mandates the following: - A conforming program is one that is acceptable to a conforming implementation. - A strictly conforming program shall use only those features of the language and library specified in the International Standard. - It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit. MISRA C:2012 enforces this by: - Rule 1.1 A standard C environment - Rule 1.3 No occurrence of undefined or unspecified behaviour - Dir 1.1 This permits the use of implementation-defined behaviour but requires that any such use is documented 13

14 Language Extensions Chapter 4 of the ISO Standard permits the following: - A conforming implementation may have extensions (including additional library functions), provided they do not alter the behaviour of any strictly conforming program. MISRA C:2012 advises against this by: - Rule 1.2 Language extensions should not be used Chapter 4 of the ISO Standard defines the following - The two forms of conforming implementation are hosted and freestanding. - A conforming hosted implementation shall accept any strictly conforming program. 14

15 Conformance: Freestanding v Hosted Chapter 4 of the ISO Standard defines the following: - A conforming freestanding implementation shall accept any strictly conforming program in which the use of the features specified in the library clause is confined to the contents of the standard headers: o <float.h> o <iso646.h> o <limits.h> o <stdarg.h> o <stdbool.h> o <stddef.h > o <stdint.h> MISRA C:2012 has no explicit library-specific restrictions on these headers 15

16 Conformance: Freestanding v Hosted MISRA C:2012 places major restrictions (including out-right prohibition) on many of the remaining standard headers: o <assert.h> Implicit restriction o <signal.h> Shall not be used o <complex.h> o <stdio.h> Shall not be used o <ctype.h> o <stdlib.h> Major restrictions o <errno.h> o <string.h> o <fenv.h> Major restrictions o <tgmath.h> Shall not be used o <inttypes.h> o <time.h> Shall not be used o <locale.h > o <wchar.h> Shall not be used o <math.h> o <wctype.h> o <setjmp.h> Shall not be used The restricts are due to the extent of the undefined, unspecified and/or implementation defined behaviour, and the functionality is mostly associated with accessing the external environment. 16

17 MISRA C Misunderstandings 17

18 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:

19 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... 19

20 Safety v Security Comparison with other guidelines 20

21 ISO/IEC TS C Secure Coding Rules 21

22 ISO/IEC TS 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 22

23 ISO/IEC TS C Secure Coding Coverage Coverage Method # Comments MISRA covers fully explicitly 22 Some rules are stricter than SecureC MISRA covers fully broad 12 Eg: bans dynamic memory, signal.h 5 Undefined/unspecified behaviour MISRA covers fully implicitly 3 Standard library MISRA covers partially broad 2 getenv() and related functions MISRA does not cover directly 2 sizeof(pointer), padding 46 23

24 ISO/IEC TS 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 [or indeed other library functions relating to a hosted environment] - 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 24

25 ISO/IEC TS 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> 5 rules Rationale - MISRA C s scope was originally freestanding application, without an operating system and/or external environment Proposal - Keep these broad approaches under review - Establish more targeted rules where appropriate 25

26 ISO/IEC TS 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 checked Some of these may benefit from additional, focussed, rules - The use of errno 1 rule - The use of character handling functions 1 rules - Use of string copying functions 1 rule 26

27 The Gaps Taintedness C Secure - Many! MISRA C: No explicit coverage of taintedness - Directives D4.1 and D4.11 cover many of the consequences. - The undefined behaviours are 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. 27

28 ISO/IEC TS Revised C Secure Coverage Coverage Method # Comments MISRA covers fully explicitly 31 MISRA covers fully broad approach 7 Eg: bans dynamic memory, signals 3 Taint MISRA covers fully implicitly 5 Undefined/unspecified behaviour MISRA covers partially or not at all 0 46 # = Coverage assuming adoption of all proposals listed. 28

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

30 CERT-C C Secure Coding Rules 30

31 CERT-C Secure Coding Standard What is CERT-C - Produced by the Software Engineering Institute (SEI) at Carnegie Mellon University. - Sponsored by the U.S. Department of Defense - Originally proposed to be adopted as an ISO standard, but this was not progressed by WG14, who progressed a subset as ISO/IEC TS instead. The MISRA C Position - We view CERT-C as complementary to MISRA C o Most rules align with the MISRA C rules o Some small variance due to difference of focus (not just safety v security) o In particular, CERT-C considers the interface to the environment in hosted applications - We are reviewing CERT-C s rules and recommendations 31

32 CERT-C (April 2014) MISRA C:2012 Coverage Coverage Method #1 #2 Comments MISRA covers fully MISRA covers partially MISRA does not cover explicitly But many are covered by directives Possible Contradictions! 1 1? But see following slides #1 Assessment presented at escrypt. #2 MISRA C Working Group preliminary assessment (MISRA C:2012 against CERT-C:Apr14) 32

33 CERT-C v MISRA C:2012 Contradiction? Array bound specification on initialization with string literals - CERT-C Rule STR11-C o 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 of the 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 length Note: MISRA C rule R9.5 only applies to Designated Initializers 33

34 CERT-C v MISRA C:2012 Contradiction? Alternative example #1 - char test[] = { [0]= a }; // Compliant to CERT-C but not MISRA C //... but really only a single character array? - char test[10] = { [0]= a }; // Compliant to MISRA C but not CERT-C //... we really wanted 10 characters Alternative 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-C //... three characters without null-terminator - char test[3] = { [0]= abcd }; // Constraint error 34

35 CERT-C v MISRA C:2012 Contradiction? Let me repeat: MISRA C:2012 rule R9.5 only applies to Designated Initializers Compare with advisory MISRA C:2012 rule R The rule Headline seems to maintain the contradiction: o When an array with external linkage is declared, its size should be explicitly specified. - And the rule Rationale explains why o Providing size information for each declaration permits them to be checked for consistency. It may also permit a static checker to perform some array bounds analysis 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 of initialization. No other MISRA C:2012 rule requires the array size to be explicitly specified. 35

36 What about C:11? 36

37 What about C:11 MISRA C Working Group has commenced a review of the deltas: - Atomic primitives - Multi-threading - Unicode characters - Appendix F/G ISO/IEC floating point - Appendix K new bounds-checking functions should allow some existing rules to be revised, with pre-c11 unsecure functions deprecated. However, though, it is possible that this section may be deleted from the standard! - Appendix L Analyzability More information in due course... 37

38 In Summary 38

39 MISRA C In Summary MISRA C is - widely respected as a safety-related coding standard - equally applicable as a security-related coding standard MISRA C has - evolved from an automotive standard into a pan-industry standard MISRA C will - continue to evolve as new editions of the C standard are produced - seek to address other constraints as they become identified 39

40 MISRA C In Summary Planned Way Ahead - Consider additional rules and/or rule revisions to address: o the gaps identified between MISRA C:2012 and ISO/IEC TS 17961:2013 o issues in the new features introduced by C11 o issues in accessing the operating environment, within hosted programs - Continue the review activity against o CERT-C o Common Weakness Enumeration o... and any other sources that may become known The MISRA C Working Group welcomes feedback from all users 40

41 Any Questions? 41

42 Arigatou gozaimasu! Thank You! I would like to acknowledge the support of the members of the MISRA C Working Group for their assistance in preparing this presentation. 42

43 References MISRA C: Embedded Security in Cars (November 2014, Hamburg) ISO/IEC TS 17961:2013 C secure coding rules CERT-C ISO/IEC 9899 CD2 comments and decisions

44 About the speaker Biography - Chairman of MISRA-C since June working group member since Over 25 years experience in developing real-time embedded software systems, across a number of industries - Chartered Fellow of the British Computer Society - Member of the Institution of Engineering & Technology Social Media 44

45 Extra Material 45

46 The Gaps Use of stdlib.h environment functions C Secure - Rule 5.29 and Rule 5.42 MISRA C: 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(), and setlocale() in locale.h 46

47 The Gaps Use of sizeof() on a pointer parameter C Secure - Rule 5.38 The Problem - Testing the sizeof a pointer passed as a parameter to a function will always return sizeof(pointer) not sizeof(underlying structure) MISRA C: 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. 47

48 The Gaps Comparison of padding data C Secure - Rule 5.9 The Problem - Unused fields in structures and/or extra characters in strings may trigger incorrect comparison results which may lead to unpredictable behaviour MISRA C: 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. 48

49 The Implicit Use of errno C Secure - Rule 5.25 The Problem - The C standard lays down certain requirements for the setting, checking and resetting of errno without which unpredictable behaviour can occur MISRA C: 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 errno Possible way ahead - Add appropriate MISRA C rules to protect against tainted values and inappropriate use. 49

50 The Implicit string copying functions C Secure - Rule 5.37 MISRA C: No explicit coverage... - Directives D4.1 and D4.11 do apply Possible way ahead - Add explicit MISRA C rule(s) - Also applies to strncpy and strncat() 50

51 The Broad string formatting functions C Secure - Rule 5.24 and Rule 5.45 MISRA C: Use of <stdio.h> generally prohibited by Advisory R 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 R

52 The Broad The use of EOF C Secure - Rule 5.16 and Rule 5.43 MISRA C: Use of <stdio.h> generally prohibited by Advisory R Directives D4.1 and D4.11 apply Ideal Solution - Ideally, the C Standard should be fixed. But given the response, when this was 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. Already known problem with too much existing practice. Possible way ahead - Add appropriate MISRA C rule(s) to protect against tainted values around EOF 52