Software Tools: Policing the standards

Chris Tapp and Jay Thomas from LDRA look at how Misra C has evolved to address security threats in today’s automotive software

Safety and reliability have long been at the heart of automotive code. Today, however, they are inseparable from security. The risk of malicious attacks has been addressed by a new set of guidelines for the widely used Misra C standard for automotive software.

The explosion of software content in today’s automobiles means almost everything in the modern car is controlled and linked by code. Software now runs from engine control to cabin air conditioning to opening and closing windows to entertainment systems and, yes, to outside communications. And that is raising serious security concerns. We have already seen an online service being able – at the request of police – to shut down and stop a vehicle being pursued. And if the good guys can get in, so can the bad guys.

Automotive software demands standards due to its pervasiveness and complexity and also because many subsystems and components are integrated into vehicles by third-party manufacturers. Today, even devices within an automobile that were not originally designed to be connected are likely accessible to a hacker once the outer communications have been breached. Compatibility, quality and security across all systems must be assured.

The Misra C guidelines define a subset of the C language for developing any application with high-integrity or high-reliability requirements. While Misra guidelines were originally designed to promote the use of the C language in safety-critical embedded applications within the motor industry, they have gained widespread acceptance in many other industries as well.

Misra guidelines help developers write high-quality code, which is by nature more safe and secure. Updates over the years have included extensions and improvements to help mitigate software-related risks for safety-critical applications, while allowing programmers to spend more time coding and less time on compliance efforts. Recently, as the embedded software content of automobiles has multiplied, industry awareness of security risks has also increased, leading to new guidelines specifically to address them.

The Misra committee, as well as other organisations, recognises that security can’t be an afterthought of development. It must be designed in from the beginning using coding best practices and rules designed to protect the safety and security of OEMs and end users. Compliance can now be tested and certified through the use of high-quality analysis tools.

Guidelines

After the publication of Misra C: 2012, the committee responsible for maintaining the C Standard published the ISO/IEC 17961: 2013 C language security guidelines. Their purpose is to establish a baseline set of requirements for analysers, including static analysis tools and C language compilers, to be applied by vendors that wish to diagnose insecure code beyond the requirements of the language standard. All rules are meant to be enforceable by static analysis. The criterion for selecting these rules is that analysers that implement these rules must be able to discover secure coding errors effectively without generating excessive false positives.

In response, the Misra committee released Misra C: 2012 Amendment 1 to support these new requirements for security. The amendment is an enhancement to, and is fully compatible with, all existing editions of the Misra language guidelines and becomes the standard approach for all future editions of the Misra guidelines.

The amendment helps developers avoid coding practices that can introduce security vulnerabilities and to write code that is more understandable and maintainable. By following these additional guidelines, developers can more thoroughly analyse their code and can assure regulatory authorities that they followed safe and secure coding practices. This is becoming especially critical in industries such as automotive, where security threats have led to stringent requirements by OEMs for developers to prove that their software meets the highest standards for security as well as safety.

In addition to the amendment to incorporate the 14 new rules, the Misra committee has also released Misra C: 2012 Addendum 2, which maps the overall coverage by Misra C: 2012 of ISO/IEC 17961: 2013 and justifies the viewpoint that Misra C is equally applicable in a security-related environment as it is in a safety-related one.

Amendment 1 establishes 14 new guidelines for secure C coding to improve the coverage of the security concerns highlighted by the ISO C secure guidelines. Several of these guidelines address specific issues pertaining to the use of tainted data, a well-known security vulnerability. A couple of specific examples illustrate common vulnerabilities and how the new guidelines address them.

Example 1: Don’t open the door to give out your password

“The validity of values received from external sources shall be checked” (Dir. 14.4)

This example controls which data can be sent to external sources. This has become critical as more and more devices are connected to each other or to the internet. If code is written incorrectly, internal data can be exposed to external sources. This rule protects against heartbleed-style vulnerabilities, in which hackers were able to extract data, including passwords, via the internet in clear text by carefully crafting appropriate messages.

The following sample code is dangerous because the length of a message received from an external source is not validated. Taking this to the logical extreme – by not validating the length of data to send back – an attacker could extract the entire contents of a computer’s memory remotely. In practice, variations of this attack have been used to extract clear text passwords from network servers’ internal memory buffers. Recently, it was used to download large volumes of customer financial information, but it could be used to capture almost any type of data.

extern uint8_t buffer[ 16 ];

/* pMessage points to an external message that is to be copied to ‘buffer’.

* The first byte holds the length of the message.

*/

void processMessage ( uint8_t const *pMessage )

{

uint8_t length = *pMessage; /* Length not validated */

for ( uint8_t i = 0u; i < length; ++i )

{

++pMessage;

buffer[ i ] = *pMessage;

}

}

Example 2: Use the right function for the right task

“The standard library function memcmp shall not be used to compare null terminated strings” (Rule 21.14)

Memcmp is designed for comparing blocks of memory, and is not designed for comparing strings such as passwords. Because it returns more than just true and false, it can be used to reveal passwords in database systems.

The following sample code uses memcmp to compare strings when strcmp should have been used.

extern char buffer1[ 12 ];

extern char buffer2[ 12 ];

void f1 ( void )

{

strcpy ( buffer1, “abc” );

strcpy ( buffer2, “abc” );

if ( memcmp ( buffer1, buffer2, sizeof ( buffer1 ) ) != 0 )

{

/* The strings stored in buffer1 and buffer 2 are reported to be

* different, but this may actually be due to differences in the

* uninitialised characters stored after the null terminators.

*/

}

}

Compliance and deviations

Inevitably, circumstances occur under which it is impracticable or unreasonable to follow all coding standards requirements. However, the concept of approved violations, known as deviations, has caused a great deal of debate, especially when discussing their effect on a claim of Misra compliance.

The result has been myriad approaches ranging from a “no deviations allowed” policy to a liberal use of deviations simply to document non-compliance. Some rules have been classified as directives, or rules where compliance is more open to interpretation or relates to process or procedural matters.

With the encouragement of large OEMs – especially in the automotive market – the Misra committee has released Misra Compliance 2016 guidance to help developers achieve and show compliance with Misra coding guidelines. This revision provides clearer guidance on the use of deviations and defines what is meant by Misra compliance. It also provides a mechanism for establishing pre-approved permits for deviation and for tailoring the classification of guidelines.

Compliance can be achieved and proven by checking code against the Misra C compliance matrix. While in theory this could be accomplished manually, the complexity and quantity of today’s software – such as the millions of lines of code now incorporated in automobiles – make that unreasonable. The primary means to check code against standards and guidelines is through the use of automated static analysis tools, which detect potential security flaws early in the process so that developers can eliminate them before code is compiled (see diagram).

Conclusion

As developers continue to add features to their products within already constrained budgets and schedules, software has become the weakest link that can allow malicious entities to breach the interface and gain access to sensitive data and/or take control of systems. In the case of the intelligent automobile, this could be devastating. Thus, writing secure code has become essential even for non-safety-critical systems.

The use of the Misra C language subset, including the Misra C: 2012 Amendment 1, helps developers write safer, more secure, and more maintainable code. With the aid of appropriate checking tools, it provides invaluable assistance to any organisation looking to protect itself from the problems inherent in the inadvertent or deliberate misuse of the C language.

A comprehensive set of analysis tools that are capable of checking standards compliance through static analysis while also providing dynamic analysis for coverage of data flow and control are essential to assure confidence and documentation of compliance both with the rules embodied in coding standards as well as the functional validity of the code produced by cooperating development teams and organisations.

Chris Tapp is a field application engineer and Jay Thomas is director of field engineering, both for LDRA