Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Andrew Banks
BSc IEng MIET FBCS CITP
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...
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.
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
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...
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”
C Secure
- Many!
MISRA C:2012
- 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.
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 17961
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
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
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:
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.
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
MISRA C:2012
http://misra.org.uk/
CERT-C
https://www.securecoding.cert.org
Biography
- Chairman of MISRA-C since June 2013...
... working group member since 2007
- 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
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: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.
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()
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
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