Remote Code Execution on the Nissan Leaf: From Bluetooth to CAN Bus Control

TLDR: Researchers at Black Hat 2025 demonstrated a multi-stage exploit chain against the Nissan Leaf ZE1, starting with a Bluetooth stack buffer overflow that leads to root-level remote code execution. By bypassing secure boot and manipulating the vehicle's internal CAN bus communication, the team achieved remote control over critical body elements like door locks, wipers, and steering. This research underscores the dangerous lack of isolation between infotainment systems and safety-critical vehicle networks.

Modern automotive security is often a house of cards built on legacy components and poorly isolated network segments. The recent research presented at Black Hat 2025 on the Nissan Leaf ZE1 is a masterclass in how a single, seemingly minor vulnerability in an infotainment system can be chained into full vehicle control. For any researcher or pentester looking at automotive targets, this talk is a mandatory study in how to move from an application-layer bug to deep system compromise.

The Initial Foothold: Bluetooth Stack Overflow

The attack begins with the Bluetooth stack, specifically the BlueDragon Evo stack used in the infotainment unit. The researchers identified a stack-based buffer overflow within the Hands-Free Profile (HFP) implementation. When the infotainment system processes incoming HFP responses, it fails to perform adequate bounds checking on the parameters passed to the handsfree_parse_response function.

Because the Bluetooth service runs with root privileges, this overflow provides an immediate path to code execution. The researchers bypassed Address Space Layout Randomization (ASLR) because, despite the mitigation being enabled, the libraries were loaded at fixed addresses. This allowed them to construct a Return-Oriented Programming (ROP) chain to execute arbitrary code.

// Simplified representation of the vulnerable parsing logic
if (GetParameters(probe_bf, probe_params, probe_lens)) {
    // Out-of-bounds copy into stack buffer
    memcpy(params, probe_params, probe_lens[0]); 
}

The exploit is remarkably efficient. By jamming the 2.4GHz spectrum, an attacker can force the vehicle to disconnect from a legitimate paired device, prompting the user to re-pair. When the user opens the "Add New" Bluetooth menu, the attacker's device can trigger the overflow, gaining root access without any further user interaction.

Persistence and Secure Boot Bypass

Gaining root access is only the first step. The Nissan Leaf employs dm-verity to ensure the integrity of the root filesystem, making traditional persistence methods like modifying system binaries impossible. To achieve persistence, the researchers targeted the secure boot chain.

They identified that the High Assurance Boot (HAB) code, which validates the firmware, was vulnerable to CVE-2017-7932. This is a stack overflow in the Certificate Signing File (CSF) processing logic. By crafting a malicious CSF, the researchers forced the system to accept arbitrary signatures. They patched the boot arguments to include ignore_corruption, effectively disabling dm-verity checks on every subsequent boot. This allowed them to modify the root filesystem and inject a persistent backdoor into the system's startup scripts, ensuring their access survived power cycles.

Pivoting to the CAN Bus

With persistent root access, the goal shifted to controlling the vehicle's body elements. The infotainment system communicates with the Renesas RH850 microcontroller, which acts as the gateway to the vehicle's internal CAN bus. The researchers discovered that the infotainment system uses a proprietary protocol over an internal SPI bus to send commands to the RH850.

By reverse-engineering the csm_proc_out.out binary, they identified the specific Unified Diagnostic Services (UDS) commands used to trigger vehicle functions. They used a CONSULT-III diagnostic tool to capture the traffic and map out the command structure.

The RH850 gateway performs some filtering, but it does not adequately restrict commands sent from the infotainment system. The researchers could send arbitrary CAN messages to the vehicle's body control module (BCM) and Advanced Driver Assistance Systems (ADAS) bus. This allowed them to remotely actuate the horn, mirrors, wipers, and even the steering wheel.

Lessons for the Field

This research highlights a critical failure in OWASP A01:2021-Broken Access Control. The infotainment system is treated as a trusted entity by the vehicle's internal network, despite being exposed to the internet and untrusted wireless protocols like Bluetooth.

For those conducting security assessments on similar systems, the takeaway is clear: do not stop at the application layer. The infotainment unit is just a gateway. Once you have code execution, look for the inter-processor communication (IPC) mechanisms—SPI, I2C, or internal UART—that connect the "smart" part of the car to the "moving" part.

Defenders must prioritize the implementation of hardware-based security modules (HSMs) that enforce strict message filtering between the infotainment system and the vehicle's safety-critical buses. Without this, the infotainment system remains a high-value target that can be turned into a remote control for the entire vehicle. If you are auditing these systems, start by mapping the SPI communication between the SoC and the gateway microcontroller, as that is where the most interesting, and most dangerous, commands are hidden.