Vulnerability-Free C and C++ development in automotive manufacturing and software defined vehicles (SDV)

The automotive industry is at a unique inflection point in its history with the advent of the Software Defined Vehicle (SDV). During the Society of Automotive Engineers (SAE) World Congress held in Detroit April 16th - 18th, 2024, it was explicitly stated there is more than a $500 billion market that will see investment in R&D and technological advancements for the automotive industry. The shift to SDV will empower new income streams through subscriptions to features and services that were impossible with the legacy “one-time buy” model inherent to the auto industry since its inception. 

Automakers and their suppliers have set out to become technology companies driven by the Electrical/Electronic (E/E) architecture, with semiconductors at the center of these innovations.  Furthermore, a critical enabler of the SDV is microservices, containerized architecture, and significant cloud computing presence. 

This sector relies almost exclusively on C and C++ software development as reliable, efficient, and robust programming languages. However, these languages have security risks such as buffer overflows and memory safety issues dating back decades. The SDV market directly correlates with Snyk’s mission to secure software. Automakers benefit from Snyk’s Infrastructure as Code (IaC) and Container offerings, and Snyk’s natural integration with various cloud providers.

For example, Mercedes is ahead of the game with their MB Operating System.

MISRA Compliance for C and C++

MISRA C:2023 guidelines primarily focus on safety and reliability in critical systems, including aspects relevant to application security, especially where vulnerabilities could lead to safety risks. While the MISRA C:2023 guidelines encompass a broad range of topics, certain rules and directives are particularly relevant to enhancing application security by promoting practices that prevent undefined behavior, memory corruption, unauthorized access, and other common vulnerabilities.

Similarly to the C guidelines, the structure and content of the MISRA C++:2023 specification outlines several rules and directives related to application security, accompanied by examples of compliant and non-compliant code.

Some of the MISRA compliance guidelines for C and C++ development cite directives and rules, such as the following, about application security and building secure C and C++ software:

• MISRA Dir 4.12 - Dynamic memory allocation shall not be used: Restricting dynamic memory allocation can prevent a class of vulnerabilities related to memory management errors.

• MISRA Rule 1.3 - There shall be no undefined or critical unspecified behavior: Undefined behavior can lead to security vulnerabilities, making this rule crucial for security.

• MISRA Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand: This rule aims to prevent out-of-bounds access, a common vulnerability in C programs.

• MISRA Rule 21.3 - The memory allocation and deallocation functions of <stdlib.h> shall not be used: Similar to Dir 4.12, avoiding dynamic memory allocation reduces risks related to memory management vulnerabilities.

• MISRA Rule 22.1 to Rule 22.20 (Resources): Proper management of resources, including error handling and resource release, is fundamental to preventing leaks and exhaustion, which can be leveraged in denial-of-service attacks or lead to undefined behavior exploitable by attackers.

While the MISRA C specification does not explicitly label guidelines as "security" measures, adherence to its comprehensive rules and directives increases the software's security posture by eliminating many common sources of security vulnerabilities in C and C++ code. The guidelines help develop safe, reliable, and secure systems by fostering robust, well-defined behavior.

Why Snyk is here to help

Snyk is dedicated to helping developers secure their code, including those working with C and C++. By integrating security into the development lifecycle like DevSecOps methods, Snyk enables developers to catch vulnerabilities before they become critical issues. Even more so, Snyk helps developers catch insecure code patterns when they save their code in the IDE and don’t have to wait until Continuous Integration (CI) and build pipelines pass, or require a code compilation step.

With tools like Snyk Code, you can scan your C and C++ codebases for vulnerabilities and get actionable insights to fix them.

For example, consider a common vulnerability in C++: the buffer overflow. Here's a simple code snippet that demonstrates this issue:

#include <iostream>
#include <cstring>

void vulnerableFunction(char* input) {
    char buffer[10];
    // ❌ Potential buffer overflow
    strcpy(buffer, input);
}

int main() {
    char input[20] = "This is a long string";
    vulnerableFunction(input);
    return 0;
}

In this example C++ program, the strcpy function can cause a buffer overflow if the input string exceeds the size of the buffer. Snyk can help identify such vulnerabilities and provide recommendations for safer alternatives, such as using strncpy:

void secureFunction(char* input) {
    char buffer[10];
    strncpy(buffer, input, sizeof(buffer) - 1);
    buffer[sizeof(buffer) - 1] = '\0'; // Ensure null-termination
}

But with Snyk installed in your IDE you get two superpowers:

1. Snyk will detect vulnerable code such as this buffer overflow, without requiring a compilation step.

2. Snyk will propose to fix it for you using Snyk’s DeepCode Fix AI 

Do you want to see this magic in action? Watch here:

By adopting secure coding practices and leveraging tools like Snyk, developers can significantly reduce the risk of vulnerabilities in their C and C++ codebases. Sign up for Snyk today and start securing your critical software projects.

Secure and compliant vs insecure and vulnerable C and C++ code examples

To show how MISRA guidelines and specifications connect to real-world code and vulnerabilities, we’ll explore a C program, program2.c, that displays an example of Undesired Behavior (MISRA Rule 1.3) from the above list.

Here's the C program code:

#include <stdio.h>

void undefinedBehavior() {
    int x = 5 / 0;
    printf("Value of x: %d\n", x);
}

int main() {
    undefinedBehavior();
    return 0;
}

Division by zero is an undefined behavior in C that can lead to unpredictable results. MISRA guidelines, rightfully so, prohibit such operations to ensure code safety and security in critical software.

Run the program by compiling first and then executing it:

$ gcc program2.c -o program2
$ ./program2

You'll notice that the GCC compiler will throw a warning about division by zero:

program2.c:5:15: warning: division by zero is undefined [-Wdivision-by-zero]
    int x = 5 / 0;
              ^ ~
1 warning generated.

However, this is a simple and small program code. In real-world scenarios, such issues can be hard to find across a large codebase and many compiler warnings piped to standard output.

Find the vulnerability with Snyk Code

Seeing the undefined behavior error message from a compiler warning about _division by zero_ and other issues can be hard to spot and late in the development cycle. Snyk Code can help you identify them early in the development cycle by scanning your codebase for vulnerabilities before compiling the code.

The reason is that Snyk employs machine learning techniques in its static code application security engine to understand program call flows and connect sink-to-source code path flows, finding insecure code and potential vulnerabilities in your codebase without compiling the code.

Tools for C and C++ Security Compliance and Secure Code

Some open-source options to check MISRA compliance in C and C++ code include the following open-source tools:

• OpenMRC: OpenMRC is an open-source MISRA-C rule checker developed as an Eclipse CDT (C/C++ Development Tooling) plugin. It's designed to analyze software-defined vehicle code against MISRA-C:2004 guidelines and produce violation messages to help developers update their source code for functional safety compliance​.

• Clang-misracpp2008: This project, albeit archived by now, aimed to create an open-source checker for the MISRA C++:2008 rules using the LLVM/Clang infrastructure. Although archived and no longer active, the developers recommend using clang-tidy-misra as an alternative. clang-misracpp2008 was implemented as an LLVM/Clang plugin, demonstrating an effort to cover MISRA C++ rules through custom logic and compiler-provided flags.

Aside from the above, whether they’re maintained to your standards and uphold the quality guardrails and comprehensive threshold for their security tests, Snyk is another option to explore.

Snyk’s security platform includes Snyk Code, a developer-focused real-time SAST that optimizes code security with a developer-friendly experience. Snyk’s findings include learning resources, example fixes for remediation advice, and sometimes even an autofix based on Snyk DeepCode AI Fix.

Snyk is free and can be employed in different methods to scan C and C++ code, such as installing the Snyk IDE extension, importing Git repositories from Bitbucket or GitHub, and using the Snyk CLI.

For C and C++ programs, another vector of security vulnerabilities in a codebase can go beyond the developer’s code: imported code through open-source libraries.

Lastly, I highly recommend going through the byte-sized and concise Snyk Learn C vulnerability educational lessons for interactive security learning experiences. The lessons cover different C and C++ vulnerabilities such as null dereference, double free bad coding conventions, and others.