MISRA C provides developers with guidelines for creating security-conscious programs and helps reduce the vulnerability of C code.
The C language continues to enjoy growing acceptance among developers. Unfortunately, however, hackers have always been able to detect and exploit existing security gaps in the code faster than the C standard could be improved with appropriate security updates. In fact, the C language poses challenges for security-critical applications, because the underlying standards (ISO/IEC 9899:2011 and 2018) lack comprehensive specifications for how implementations should behave. While this omission gives both developers and independently developed software packages more flexibility in managing system resources and memory access, this flexibility can lead to unpredictable behavior. Bottom line, this potentially results in code,
MISRA C remains the leading body of guidelines for writing code that is safe, secure and reliable for embedded systems from automotive to avionics to medical devices.
Even if the opposite is often claimed, MISRA C was never specifically designed for the safety aspect, but has always been suitable for use with security-critical code. MISRA C defines a subset of the C language that reduces or completely eliminates the possibility of errors. Thus code written in accordance with MISRA C is very likely to be of high quality, and high quality code is in turn very likely to be both safe and secure.
With the latest release of MISRA C:2012 Amendment 4 (AMD4), released in April 2023, MISRA is more relevant than ever. Thanks to the new amendment, MISRA C:2023 combines all previous editions and technical corrigenda of MISRA C into one document and thus addresses the enormous challenge that configuration management has posed for development teams.
For C developers, using automated verification tools that include the latest MISRA guidelines is a best practice for writing code that is more safe and secure. While there are C compilers that can identify risky coding, the more efficient and cost-effective way is to prevent problems before they even find their way into the codebase. Using a static analysis tool for automated MISRA C compliance helps uncover and fix issues at the earliest possible stage and supports developers in many ways in their efforts to produce more secure code:
Reducing the risk of common programming errors. The MISRA C Guidelines contain rules for avoiding common coding errors that can lead to security gaps. For example, there are rules that require explicit typing, restrict the use of pointer arithmetic, or specify requirements for variable initialization.
Many requirements related to the functional safety of the code also apply to security. In addition, the compilation of explicit guidelines to avoid known security vulnerabilities provides both developers and static analysis tools with a framework to improve the security properties of applications. MISRA C contains 14 guidelines for security-aware programming in C, covering the security concerns highlighted in the ISO C Secure Guidelines. Several of these policies address specific issues related to the use of untrusted data, which is a known security vulnerability. A few examples from the guidelines can help demonstrate some subtle things that can lead to serious problems,
Example 1: Do not open doors to malicious actors
“Check the validity of values received from external sources” (Directive 4.14)
This directive affects the receipt of data from external sources – an issue that has become very important due to the growing number of devices that are connected to each other or to the Internet. In order to offer as few points of attack as possible, such data must be validated.
The adjacent code snippet represents a potential security vulnerability because the length of messages received from an external source is not checked. Copying the full length of data to a buffer, exceeding the allocated memory space, presents a security vulnerability that attackers can use to corrupt the system or cause even greater damage.
The directive implies the need for “defensive” code to continually check not only whether the received data fits within the expected framework (as in the example), but also whether it makes sense. For example, a record of commands received over time can reveal abnormal usage patterns that may indicate a denial-of-service attack, for example.
Example 2: Using the right function for the right task
“The standard library function memcmp shall not be used to compare null-terminated strings.” (Rule 21.14)
The memcmp() function is intended to compare the contents of memory blocks. However, it must not be used to compare strings such as passwords, because it outputs more than one true or false value and is therefore suitable for revealing passwords in database systems. It returns a zero value if both buffers have the same content, while a positive or negative value is returned if the content is different. If it is implemented as a calculation and the value on one side is checked, the function can be called repeatedly until the value on the other side, which can be a password, for example, is determined. In fact, the man page for memcmp() explicitly states that
In the code sample (left), memcmp() is used to compare strings when strcmp() should actually be used.
Example 3: If someone controls the way you speak, they can make you say anything they want
“The pointer returned by the standard library functions asctime, ctime, gmtime, localtime, localeconv, getenv, setlocale, or strerror must not be used in a subsequent call to the same function.” (Rule 21.10)
Local messages control the formatting of strings, effectively defining the way the software “speaks”. So once hackers gain control over the formatting of strings, they can enforce the statements they want, such as controlling which other programs the first program interacts with. Consequently, these strings can be used to execute arbitrary commands and get hold of a system.
The code example below may not work as intended because the second call to setlocale() may result in the string referenced by “res1” which is the same as that referenced by “res2”. Aside from correctness, locale checking has been used in exploits in which strings have been reformatted to make it easier to process commands on a remote computer.
Due to the complexity and scope of today’s software, it is unrealistic to carry out the MISRA C conformity check manually. Instead, automatic static analysis tools are primarily used to check code for compliance with standards and guidelines. Finding and correcting violations of these guidelines requires static analysis tools that have these guidelines built in and can uncover potential security flaws at a very early stage, so developers can correct them before the code is compiled. (mbf)
Author – Mark Pitchford works with development teams seeking compliant software development in safety-critical environments, using standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0. He is a technical specialist at LDRA Software Technology.
14 Jun 2023
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707