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

July 14, 2015 2

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

July 14, 2015 3

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)

July 14, 2015 4

MISRA-C – The 2012 Edition

Published early 2013 159 Guidelines in total

• 16 Directives
• 9 Required
• 7 Advisory
• 143 Rules
• 10 Mandatory
• 101 Required
• 32 Advisory

A compliance and deviation policy

July 14, 2015 5

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.

July 14, 2015 6

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
• Compatible with MISRA C:2012 (and any future versions)
• Compatible with MISRA C++:20xx
• No reason it cannot be applied to earlier versions of either document!

And a few other things...

• Looking at C11 amongst them

July 14, 2015 7

MISRA C

Misunderstandings

July 14, 2015 8

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

July 14, 2015 9

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

July 14, 2015 10

ESCAR 2014, Hamburg

July 14, 2015 11

MISRA C Directives

Guidelines that are not Rules!

July 14, 2015 12

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!

July 14, 2015 13

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

July 14, 2015 14

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
• f 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!)

July 14, 2015 15

Safety v Security

Comparison with other guidelines

July 14, 2015 16

ISO/IEC TS 17961

C Secure Coding Rules

July 14, 2015 17

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”

July 14, 2015 18

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 MISRA covers fully – implicitly 6 Undefined/unspecified behaviour 3 Standard library MISRA covers partially – broad 2 MISRA does not cover directly 2 46

July 14, 2015 19

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

July 14, 2015 20

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

July 14, 2015 21

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()

July 14, 2015 22

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.

July 14, 2015 23

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.

July 14, 2015 24

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

• The use of string formatting functions
• The use of EOF

Proposal

• Keep these broad approaches under review
• Establish more targeted rules where appropriate

July 14, 2015 25

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

July 14, 2015 26

The Broad – The use of EOF

C Secure

• Rule 5.16 and Rule 5.43

MISRA C:2012

• Use of <stdio.h> generally prohibited by Advisory R21.6
• 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

July 14, 2015 27

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

July 14, 2015 28

The Implicit – Use of errno

C Secure

• Rule 5.25

MISRA 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 errno

Possible way ahead

• Add appropriate MISRA C rules to protect against tainted values and

inappropriate use.

July 14, 2015 29

The Implicit – string copying functions

C Secure

• Rule 5.37

MISRA C:2012

• 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()

July 14, 2015 30

ISO/IEC TS 17961 – Revised C Secure Coverage

Coverage Method # Comments MISRA covers fully – explicitly 31 MISRA covers fully – broad approach 7 Eg: bans dynamic memory, signals MISRA covers fully – implicitly 3 Taint 5 Undefined/unspecified behaviour MISRA covers partially or not at all 46

July 14, 2015 31

ISO/IEC TS 17961 – The Next Steps

Proposed Next Steps

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

July 14, 2015 32

CERT-C

C Secure Coding Rules

July 14, 2015 33

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 ISO/IEC TS 17961 instead. The MISRA C Position

• We view CERT-C as complementary to MISRA C
• Most rules align with the MISRA C rules
• Some small variance due to difference of focus (not just safety v security)
• We are reviewing CERT-C’s rules and recommendations

July 14, 2015 34

CERT-C (April 2014) – MISRA C:2012 Coverage

Coverage Method #1 #2 Comments MISRA covers – fully 36 42 MISRA covers – partially 18 22 MISRA does not cover explicitly 41 33 But many are covered by directives Possible Contradictions! 1 1 96 98

#1 Assessment presented at escrypt. #2 MISRA C Working Group assessment (MISRA C:2012 against CERT-C:Apr14)

July 14, 2015 35

CERT-C v MISRA C:2012 Contradiction?

Array bound specification on initialization with string literals

• CERT-C Rule STR11-C
• Do not specify the bound of a character array initialised with a string literal
• MISRA C:2012 rule R9.5 (Required)
• 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

July 14, 2015 36

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-CC // ... three characters without null-terminator

• char test[3]

= { [0]=“abcd” }; // Constraint error

July 14, 2015 37

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 R8.11

• The rule Headline seems to maintain the contradiction:
• When an array with external linkage is declared, its size should be explicitly

specified.

• And the rule Rationale explains why
• 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:
• 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.

July 14, 2015 38

In Summary

July 14, 2015 39

MISRA C – In Summary

MISRA C is

• widely respected as a safety-related coding standard
• equally applicable as a security-related coding standard

Proposed 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 against
• CERT-C
• Common Weakness Enumeration
• ... and any other sources that may become known
• The MISRA C Working Group welcomes feedback from users

July 14, 2015 40

Any Questions?

July 14, 2015 41

Danke Schön 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.

July 14, 2015 42

References

MISRA C:2012

http://misra.org.uk/

Embedded Security in Cars (November 2014, Hamburg)

https://www.escar.info/history/escar-europe/escar-europe-2014-lectures-and-program-committee.html

ISO/IEC TS 17961:2013 – C secure coding rules

http://www.iso.org/iso/catalogue_detail.htm?csnumber=61134

CERT-C

https://www.securecoding.cert.org

ISO/IEC 9899 CD2 comments and decisions

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n847.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n872.htm

July 14, 2015 43

About the speaker

Biography

• Chairman of MISRA-C since June 2013
• 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 AndrewBanks.com @AndrewBanks https://linkedin.com/in/AndrewBanks

July 14, 2015 44