By Omar Yang (Senior Threat Researcher, Automotive)
In 2019, Microsoft revealed that around 70% of the vulnerabilities disclosed in its products stemmed from memory-related issues. Fast-forward to 2024, and the Zero Day Initiative (ZDI) reported that memory-related Common Weakness Enumerations (CWEs) remained at the forefront of software security concerns. Rust, a programming language designed to focus on memory safety, is purported to prevent these memory-related errors. Major players such as Microsoft and Linux are already rewriting portions of their libraries using it. Considering this growing adoption of Rust, we tackle its potential impact on automotive cybersecurity.
On the upside
Significant decrease in memory-related vulnerabilities
As a programming language that interfaces seamlessly with both hardware and software, Rust presents a promising alternative to C for programming vehicle components. Unlike C, which was developed for the Unix system and allowed extensive direct memory access, Rust prioritizes memory safety.
According to Google’s security blog, memory safety vulnerabilities significantly decreased from 2019 to 2022, from 223 to 85. A similar reduction in vulnerabilities can be anticipated in the automotive industry if Rust is employed in automotive firmware and software. Over time, decreasing memory safety issues can reduce maintenance efforts and increase efficiency.
Memory-related vulnerabilities have been a critical concern in the automotive industry for decades. For instance, the development of MISRA-C/C++ standards has been aimed at addressing security issues in embedded systems. Initially proposed in 1998 and revised subsequently, MISRA-C/C++ continues to evolve in response to emerging security challenges.
On the downside
Learning curve and ‘unsafe’ feature
Rust’s memory safety is underpinned by principles such as ownership, which stipulates that only one entity can access a piece of memory at a time. This represents a significant departure from other programming languages and often leads to a steeper learning curve and extended development times for software projects. Furthermore, Rust includes an “unsafe()” feature, intended for instances where adherence to Rust’s strict memory safety rules is impractical. However, this feature can be misused to bypass compiler checks, potentially leaving vulnerable code in place.
Vulnerabilities in the language and toolchains
Using Rust does not inherently guarantee security, as the language and its toolchains can also contain vulnerabilities. For example, in April 2024, a critical vulnerability identified as CVE-2024-24576 was disclosed, which allowed for arbitrary code execution via cmd.exe in a Windows environment. Additionally, the machine code generated by compilers might not fully align with the language specifications or could contain bugs, potentially compromising the source code in the process.
Ecosystem and third-party libraries
As with many emerging languages, Rust relies on components from more established languages, potentially lowering the development priority for functionalities that already exist elsewhere. While reusing counterparts from other languages can be tempting, this can compromise Rust’s security features. For instance, invoking functions from other languages can negate Rust’s memory safety guarantees. This is highlighted by incidents involving malicious packages in ecosystems like Node Package Manager (NPM). Using third-party libraries to develop electronic control unit (ECU) firmware may expedite delivery but also introduce potential vulnerabilities.
Non-memory CWEs and other attack vectors
Despite a notable reduction in vulnerabilities, Rust addresses only memory-related issues, which made up only half of the top 10 CWEs in 2023 — meaning half were not related to memory safety. Rust does not mitigate design flaws such as inadequate input validation, which can lead to command injections or unauthorized access via path traversal. In addition, Rust cannot prevent hardware-focused attacks such as side-channel attacks (which exploit information leaked from a system’s physical implementation, rather than its algorithmic weaknesses) or fault injections (which involve deliberately introducing errors into a system). For instance, in August 2023, researchers from the Technical University of Berlin successfully conducted a voltage glitch on Tesla’s hardware to bypass secure boot protocols.
Figure 1. Half of the top 10 CWEs in 2023 were not related to memory safety, according to data from the ZDI.
Conclusion
Rust offers distinct advantages and poses a strong alternative to C/C++ in programming. However, transitioning automotive firmware and software to Rust, or any programming language for that matter, does not definitively guarantee the security of connected cars or their components. It’s not a silver bullet, not the proverbial panacea for the automotive industry’s cybersecurity woes.
Rather, it is imperative to monitor a vehicle’s internal and external communications proactively. Promptly detecting and addressing vulnerabilities across all layers of technology — from hardware chips to operating systems, from system drivers to user applications — is essential to ensuring the security of connected vehicles. Additionally, software development involves both proprietary and open-source software. With the increased adoption of open-source software in software-defined vehicles (SDVs), it is important to consider monitoring open-source software vulnerabilities alongside proprietary software vulnerabilities to ensure a more comprehensive approach.
For more insights on automotive cybersecurity, visit our resource center and read our other blog entries.
