Why undefined behaviors are the greatest threat to automotive software security and ISO/SAE 21434 compliance

In the first post of this series, we introduced ISO/SAE 21434 in the context of automotive software development. We looked at how recent trends in the industry are rapidly increasing vehicle attack surfaces, and the challenges developers face in ensuring adequate cybersecurity and complying with ISO/SAE 21434.

In this post, we’ll examine the vulnerabilities hackers most often exploit to gain access to a vehicle’s systems and why they’re so dangerous. But first, we’ll look at why these vulnerabilities are so prevalent in automotive software and firmware.

This post is Part 2 of a 3-part series derived from TrustInSoft’s new white paper,  “ISO/SAE 21434 from a Software Development Perspective: How sound, exhaustive static analysis can help ensure air-tight automotive cybersecurity while lowering its costs.”     

To get your FREE copy, CLICK HERE. 

In our previous post, we looked at the variety and growth of cybersecurity attack surfaces in automotive systems. Of those attack surfaces, perhaps the largest and fastest growing consists of source code. Unfortunately, the fact that most automotive software and firmware is programmed in C or C++ puts vehicles at a high risk of cyberattack… if that risk is not properly mitigated.

Security weaknesses of the C/C++ programming language

The C and C++ programming languages are well known as being “memory-unsafe languages.”1 What that means is that C and C++ do not prevent programmers from making coding mistakes that can introduce bugs related to how a program uses memory.

Types of memory safety bugs include, among others:

• Buffer overflow
• Integer overflow and underflow
• Use after free
• Null pointer dereferencing

Memory safety bugs are extremely common. A recent study found that 60-70% of vulnerabilities in Apple’s iOS and macOS operating systems are memory safety vulnerabilities.2 Apple’s chief competitor, Microsoft, estimates that 70% of all vulnerabilities in their products over the last decade have been memory safety issues.3

Even Google is heavily affected. They estimated that 90% of Android vulnerabilities are memory safety issues.4 And an analysis by Google of zero-day vulnerabilities being exploited in the wild found that more than 80% of them were memory safety issues.5

Finally, in the automotive sector, a study by IOActive found that automobiles “are plagued by many serious vulnerabilities that malicious actors can exploit to gain access to a vehicle’s systems.” 6

The most common types of vulnerabilities found by researchers are information disclosure issues, coding logic errors, undefined behaviors, hardcoded credentials, backdoors, and vulnerable dependencies (e.g. use of outdated libraries). Some of these are relatively easy to correct. Others are extremely difficult to detect and eliminate.

Among the most difficult vulnerabilities to detect are the group classified as undefined behaviors.

Undefined behaviors

An undefined behavior (UB) is the result of executing a program whose behavior is prescribed to be unpredictable. UBs can cause programs to crash, produce incorrect results, or permit unauthorized access. Unauthorized access could allow a hacker to inject malicious input data or malware or alter the program’s functionality.

Undefined behavior errors are extremely common in C and C++. The C/C++ compiler has no rules to prevent these UB conditions from occurring. Thus, it allows the code to compile. This is one of the reasons C and C++ are considered memory-unsafe languages.

Besides being very common, UBs are also very dangerous.

Figure 2: 2022 CWE Top 25 Most Dangerous Software Weaknesses

Six of Mitre’s CWE Top 25 Most Dangerous Software Weaknesses in 20227 were undefined behaviors (highlighted in green in Figure 2). The rankings were similar in 2021.

CWE stands for Common Weakness Enumeration, Mitre’s method for identifying and numbering security flaws in software and a widely accepted reference for vulnerabilities classification.

All six of these vulnerabilities ranked amongst the highest in occurrence, as indicated in the column labeled “Nbr CVE” in Figure 2.

CVE stands for Common Vulnerability and Exposure and indicates the number of occurrences of the CWE recorded in one of the public CVE databases managed by MITRE and NIST.

The “Score” column in Figure 2 indicates the relative danger from each CWE. Each CWE’s score is computed from CVE and Average Common Vulnerability Scoring System (Avg CVSS). CVSS is a way to measure the severity of a CVE. Each CVE occurrence has its own CVSS. “Avg CVSS” is the average calculated CVSS across all recorded occurrences (CVE) of a given CWE.

Buffer Overflows dominate the exploitable vulnerability field. Buffer Overflow UBs represent 25% of all CVEs across all applications. Undefined behaviors in general make up 37% of overall CVEs.

In embedded applications, where web vulnerabilities (XSS, CSRF, SQL Injection, SSRF, etc.) are irrelevant, undefined behaviors are even more dominant.

Figure 3: UB share of embedded code vulnerabilities (2022 CWE Top 25)

If we look at the occurrences of CWEs in embedded code and weight the share of each based on Mitre’s CWE Score (to account for the fact that some vulnerabilities are more exploitable than others), Buffer Overflows (CWE-787, CWE-125 and CWE-119) represent nearly 50% of embedded vulnerabilities, as illustrated in Figure 3.

Undefined Behaviors as a whole constitute nearly 66.2% of embedded vulnerabilities based on Score.

Why undefined behaviors are dangerous

Undefined behaviors are very subtle and very difficult to detect. They tend to be identified by hackers (white hat or black hat) who probe software through an assortment of automated and highly sophisticated methods. They can’t be discovered through rule checking or syntactic analysis. Systematic detection of UBs requires a specialized, purpose-built tool.

An example of dangerous UBs in automotive SW/FW

In August 2021, BlackBerry publicly disclosed that its QNX Real Time Operating System (RTOS) is affected by a BadAlloc vulnerability.8

NIST characterized this flaw as “an integer overflow vulnerability [CWE-190] in the calloc() function of the C runtime library of affected versions of BlackBerry® QNX Software Development Platform (SDP)… that could allow an attacker to potentially perform a denial of service or execute arbitrary code.” NIST gave this weakness a base vulnerability score of 9.8/10 (critical).9

QNX RTOS is used in automotive applications for critical functions like advanced driver assistance systems (ADAS), where memory allocation issues could lead to tragedy. It has been integrated into 195 million vehicles and is “the embedded software of choice for 23 of the top 25 electric vehicle makers,” according to the manufacturer. Affected automotive OEMs include Volkswagen Group, BMW, Ford, and others.

According to CISA, this vulnerability is remotely exploitable. “A remote attacker could exploit CVE-2021-22156 to cause a denial-of-service condition or execute arbitrary code on affected devices. A compromise could result in a malicious actor gaining control of highly sensitive systems.”10

Possible consequences of the exploitation of this vulnerability could include the loss of vehicle control due to compromise of safety-critical functions, and injury or death to vehicle occupants or other persons resulting from an accident.

The manufacturers resisted making a public announcement of the flaw, because they do not have a solution. Nevertheless, CISA has strongly encouraged critical infrastructure organizations and other organizations who are developing, maintaining, supporting, or using affected QNX-based systems to patch affected products as quickly as possible.11

This is just one example of an uncaught undefined behavior that made its way into automotive software and put vehicle passengers and the general public at risk. There have been others. Our latest white paper, ISO/SAE 21434 from a Software Development Perspective, looks at two additional examples.

This post is Part 2 of a 3-part series derived from TrustInSoft’s new white paper, “ISO/SAE 21434 from a Software Development Perspective: How sound, exhaustive static analysis can help ensure air-tight automotive cybersecurity while lowering its costs.” 

To get your FREE copy, CLICK HERE.

In our next post…

Earlier, we mentioned that systematic detection and removal of undefined behaviors requires a specialized, purpose-built tool. In Part 3 of this series, we’ll see how one such tool—our own TrustInSoft Analyzer—can totally eliminate UBs from automotive software and lower the cost of ISO/SAE 21434 compliance.

For additional information, see our white paper

If you find this post useful, our new white paper, ISO/SAE 21434 from a Software Development Perspective, contains a more detailed discussion of all the topics covered in this blog series, as well as additional examples and some case studies. 

References

1. Caballar, R., The Move to Memory-Safe Programming, IEEE, March 2023.
2. Kehrer, P., Memory Unsafety in Apple’s Operating Systems, Paul Kehrer, July 2019.
3. Levick, R., Fernandez, S., We need a safer systems programming language, July 2019.
4. Vander Stoep, J., Zhang, C., Queue the Hardening Enhancements, Google, May 2019.
5. Hawkes, B., 0day “In the Wild”, Google, May 2019.
6. Kovacs, E., Cars Plagued by Many Serious Vulnerabilities: Report, SecurityWeek, August 2016.
7. 2022 CWE Top 25 Most Dangerous Software Weaknesses, Mitre Corporation, June 2022.
8. ICS Advisory: BadAlloc Vulnerability Affecting BlackBerry QNX RTOS, CISA, August 2021.
9. National Vulnerability Database, CVE-2021-22156 Detail, NIST, August 2021.
10. ICS Advisory: BadAlloc Vulnerability Affecting BlackBerry QNX RTOS, CISA, August 2021.
11. ICS Advisory: BadAlloc Vulnerability Affecting BlackBerry QNX RTOS, CISA, August 2021.