Unmasking Hidden Vulnerabilities in AUTOSAR

AUTOSAR is a universally adopted software framework used across various automobile components such as ABS, ECU, automatic lighting, climate control, charge controllers, infotainment systems, and more. It was created with the purpose of facilitating a standard interface among vehicle components, promoting interchangeability between different manufacturers. 

Consequently, any automotive component equipped with a microcontroller unit (MCU) is expected to conform to AUTOSAR’s stipulations.

The AUTOSAR standard governs not just the data format employed for inter-module communication, but also mandates a standard API for these modules. There exist two versions of the AUTOSAR platform in use within the automotive industry: Classic and Adaptive. 

The Adaptive platform is tailored for high-performance devices, such as infotainment systems or Advanced Driver-Assistance Systems (ADAS), which frequently run on rich operating systems like Linux or QNX. On the other hand, the Classic platform is deployed in lower performance devices running on bare-metal microcontroller units (MCUs), including systems like ABS, EBD, Airbag Control Units, Body Control Modules, Transmission Control Modules, and more.

While AUTOSAR is a robust and reliable development framework, it’s not devoid of potential errors and vulnerabilities. During an internal analysis of an AUTOSAR file, we stumbled upon a particularly intriguing vulnerability that could pose numerous security risks. The flaw in the code wasn’t inherently due to AUTOSAR itself but rather, a result of its improper usage. 

In this article, we intend to delve into and dissect this specific case.

Firmware, in most cases, is developed utilizing toolchains supplied by the two leading AUTOSAR software providers: Vector and Elektrobit. 

Both offer a configuration tool and an SDK, which includes pre-built implementations for standard AUTOSAR modules such as the MicroSAR OS runtime, CAN interface, NVM API, Diagnostics module, Cryptography, and Memory interface among others. This kind of SDK is known as Basic Software (BSW), serving as middleware and therefore cannot independently run on target hardware.

In addition to BSW, there’s a suite of drivers and libraries known as the Microcontroller Abstraction Layer (MCAL), facilitating access to the hardware. Every hardware manufacturer intending for their MCUs to be utilized in the automotive industry provides an AUTOSAR MCAL for their MCUs. For instance, there are MCALs from Bosch, NXP, Renesas, and Infineon. MCAL drivers and libraries are also standardized by AUTOSAR to ensure that BSW can be used with MCAL from any hardware manufacturer.

The development of new firmware typically begins with the configurator tool. Here, the developer establishes the hardware platform to be used, selects the required MCAL and BSW modules for their project, and then sets up the connections between all modules. For example, they might specify which MCAL’s CAN interface should be utilized by the CanIf module from BSW. Once the configuration phase is finished, the configurator tool produces the source code, which essentially is a subset of MCAL and BSW.

After the source code is generated, it can be compiled with any compiler or Integrated Development Environment (IDE), and then installed on the target device. The source code, as output by the configurator, already encompasses everything necessary for the device to operate with default behavior. As such, developers may not need to modify anything in the generated code. Any custom code that is layered on top of BSW is typically minimal, often accounting for less than 10% of the total firmware size.

In our role conducting red-team penetration testing, we obtained firmware based on AUTOSAR for security evaluation. Viewed from the standpoint of both the attacker and the penetration tester, the potential points of attack in AUTOSAR-based files are significantly limited. The modules’ source code is remarkably solid, consistently undergoing through code review and vulnerability analysis.

Regarding conventional vulnerabilities and Common Weakness Enumerations (CWEs), the potential for discovery is rather slim. There is no dynamic memory allocation, and all variables are either global or on the stack, eliminating the chance to uncover vulnerabilities like double-free or use-after-free. Automotive code doesn’t perform string operations, but focuses solely on binary parsing. As a result, the likelihood of encountering stack overflows through operations like sprintf, sscanf, strcpy, etc., is non-existent here.

When it comes to potential race condition vulnerabilities, AUTOSAR classic doesn’t allow for dynamic task initiation or the dynamic creation of synchronization primitives. The list of tasks and synchronization events are predetermined during the configuration phase. Therefore, the likelihood of auto-generated code containing deadlocks or race conditions is unlikely, given the static, pre-configured set of task resources and events.

Thus, we had to delve further into the AUTOSAR framework – understanding its usage and potential misuse of the API – specifically focusing on how a user might invoke it in a manner that could lead to vulnerabilities.

We came across a set of functions in the NvM module: NvM_ReadBlock, NvM_WriteBlock, and NvM_RestoreBlockDefaults, commonly utilized for loading and storing device settings in NVM (such as EEPROM, NAND, NOR memory, etc).

Upon examining the function prototypes in the Specification of NVRAM Manager:

It’s clear that these functions lack buffer size checking. They solely use a block ID to determine the data size from a special block table configured during the configuration phase. In other words, it’s the responsibility of the user to include code that verifies the data saved in the NvM block is an appropriate size when writing. Similarly, the onus is on the user to provide a sufficiently large buffer when reading from the NvM block, as NvM_ReadBlock will simply overwrite the buffer according to the size of the NvM block.

Therefore, such API calls could potentially lead to Out of Bounds (OOB) read/write. Depending on the type of buffer passed as NvM_DstPtr/NvM_SrcPtr, various issues may arise:

• If the user provides a small stack variable but reads a large NvM block, NvM_ReadBlock will write data outside of the stack variable, causing stack corruption and potentially opening the door for Remote Code Execution (RCE).
• If the variable provided was a global one, NvM_ReadBlock will overwrite the neighboring global variables. This could cause undefined behavior in the code going forward.
• If the user provides a small stack or global variable for NvM_WriteBlock, it will lead NvM_WriteBlock to read data outside of the variable and store random data into NVM.

Utilizing this approach, we discovered an intriguing case of AUTOSAR API misuse, leading to a buffer overflow vulnerability.

Let’s look at a simplified version of the vulnerability that we encountered:

NvM_ReadBlock will read 0x110 bytes from NVM and then write it at the location of myVar. While it will accurately write the value of myVar, it will then proceed to overwrite the neighboring global variables with unpredictable values.

In the case that we found, NvM_ReadBlock is set to perform an out-of-bounds write on the stack, which could overwrite the return address of the function.

In our specific case, the call to the vulnerable function was obscured by the intricate custom workflow of the MCU. However, it was still triggerable, and indeed resulted in an execution crash.

After the code generation process, managing the sizes of the variables being used with the NvM API in the source code falls solely on the developer’s shoulders. Therefore, AUTOSAR developers should make every effort to align the sizes of the variables and the NVM block in the configurator. They also should avoid altering the generated code afterward, unless they fully comprehend the constraints regarding the NVM block size.

Furthermore, no NVM function can provide the size of the NVM block to execute checks like: assert(sizeof(myVar) == NvM_BlockSize(Block_ID)); This is because block sizes are hard-coded into the NvM module configuration and considered internal data.

Even while utilizing standardized frameworks such as AUTOSAR, under certain circumstances, one could inadvertently introduce significant memory vulnerabilities. To mitigate such instances, continuous quality assurance measures and regular penetration testing are strongly recommended.

While AUTOSAR offers a robust and standard framework for automotive software development, potential vulnerabilities can still emerge due to improper usage, particularly in variable management within the NvM API. As the complexity of automotive technology continues to grow, it’s essential to reinforce software security through continuous quality assurance and regular penetration testing. These practices, paired with a deep understanding of the frameworks in use, can help developers mitigate potential security risks and enhance the overall safety of automotive systems.