Unlocking the Drive: Exploiting Tesla Model 3

Unlocking the Drive: Exploiting Tesla Model 3

Speakers: David Berard, Vincent Dehors

Conference: GreHack

YouTube: https://www.youtube.com/watch?v=pmANkTFGh1k

Overview

In this highly technical talk at GreHack, David Berard and Vincent Dehors from Synacktiv unveiled the intricate multi-stage exploit chain they developed to compromise a Tesla Model 3. Their research, initially conducted for the prestigious Pwn2Own automotive competition in Tokyo, demonstrated a complete takeover of the vehicle's infotainment system, escalating privileges to kernel-level access, and ultimately gaining control over the Security Gateway. This comprehensive attack chain highlights critical vulnerabilities across various components, from the Bluetooth stack to the Wi-Fi chipset driver and the car's central microcontroller unit (MCU).

The research is particularly significant as it showcases a remote code execution (RCE) vulnerability in the Bluetooth stack that, when chained with further exploits, allows an attacker to achieve root privileges on the infotainment system and then pivot to the Security Gateway. The speakers meticulously detail each step of the exploit, revealing architectural flaws, misconfigurations, and logic bugs that enabled them to bypass multiple layers of security. Their findings underscore the importance of robust security measures in complex automotive systems and the potential impact of seemingly minor vulnerabilities when combined strategically.

This presentation serves as a crucial case study for both automotive manufacturers and security researchers, illustrating the depth of analysis required to uncover such sophisticated attack vectors. The successful exploitation, which earned them a "Master of Pwn" title, not only demonstrated a profound understanding of the Tesla architecture but also provided actionable insights into hardening connected car systems against advanced persistent threats. The talk emphasizes that even well-developed software can harbor exploitable logic flaws, especially in complex interactions between different hardware and software components.

Background

▶ Watch: Introduction and Pwn2Own Tesla target context (0:00)

The context for this research stems from Synacktiv's participation in the Zero Day Initiative's (ZDI) Pwn2Own competition, specifically the automotive category. Their prior work on Tesla cars for Pwn2Own 2022 had already yielded significant findings, including a bug in the network manager leading to code execution in the infotainment system from Wi-Fi, without user interaction. This earlier success provided them with initial access and a deeper understanding of the Tesla architecture, which proved invaluable for their subsequent research. The Pwn2Own competition incentivizes researchers to find and exploit vulnerabilities in various targets, pushing the boundaries of security research.

Tesla's vehicle architecture is designed with a strong emphasis on separation of concerns. The main components include the infotainment domain, responsible for multimedia and entertainment, and the vehicle domain, which handles critical car functions. These domains are interconnected but ideally isolated, exchanging information like CAN matrix data. A crucial component in this architecture is the Security Gateway, which acts as a bridge between the infotainment and vehicle domains, filtering CAN messages and providing sensitive information. The infotainment processor, an Intel x86 for older models (like the one studied) and an AMD x86 for newer ones, includes Wi-Fi and Bluetooth chips connected via PCI. The infotainment board is also connected to the Security Gateway MCU via Ethernet.

The researchers' methodology involved a combination of static and dynamic analysis. For dynamic analysis, they leveraged SSH access to the infotainment system, which allowed them to attach debuggers and monitor system behavior in real-time. This access, likely obtained from previous Pwn2Own entries or Tesla's security researcher program (which offers access to infotainment boards for a year after a successful root), was critical for efficiently developing and refining their exploits. The target for this particular research was BlueZ, a popular Bluetooth stack used in Linux, and specifically the BServer component within the Tesla infotainment system, which handles Bluetooth communications. The team acquired multiple infotainment boards from sources like eBay and through Tesla's security program to facilitate their hardware-level research.

Key Findings

▶ Watch: Bluetooth RCE: OBEX Heap Overflow in B-Server (13:00)

The core contribution of this research is a sophisticated, multi-stage exploit chain that demonstrates a complete compromise of the Tesla Model 3's infotainment system and subsequent pivot to the Security Gateway. The main discoveries and contributions can be summarized as follows:

1. Bluetooth Remote Code Execution (RCE) via Heap Overflow: The researchers identified a critical heap overflow vulnerability within the BServer process, Tesla's custom Bluetooth application. This vulnerability, located in the Object Exchange Protocol (OBEX) image parsing function, allowed for arbitrary global write primitive due to the BServer binary being compiled without Position Independent Executable (PIE), making memory addresses predictable. This provided the initial entry point for the attack.

1. Sandbox Escape and Wi-Fi Firmware Code Execution: After gaining RCE in BServer, the team faced sandboxing restrictions (seccomp, AppArmor, mini-jail). They discovered that BServer could communicate with the Bluetooth chipset using HCI protocol vendor commands. Exploiting a lack of isolation, they leveraged shared internal RAM between the Bluetooth and Wi-Fi components of the combo chip to write arbitrary code into the Wi-Fi firmware. By patching the Wi-Fi firmware and hijacking its idle task, they achieved code execution on the Wi-Fi chipset's ARM core (Stage 2).

1. Linux Kernel Local Privilege Escalation (LPE) from Wi-Fi Chipset: From the Wi-Fi chipset, connected to the main processor via PCI Express and using DMA, the attackers targeted the bcmdhd Linux driver. They found a vulnerability where an offset in a shared structure was used without being checked, allowing them to write past the mapped region of the Wi-Fi chipset memory into the kernel's vmalloc region. By combining this with a kernel stack spray and an ASLR bypass (via a cache channel attack), they constructed a Return-Oriented Programming (ROP) chain to achieve root privileges on the infotainment system (Stage 3).

1. Security Gateway Compromise via Logic Bug: With root access on the infotainment, the final stage involved compromising the Security Gateway. They identified a critical logic bug in the Gateway's updater mode. By manipulating the TFTP update process (sending a valid firmware for signature check, then immediately sending an invalid one that overwrites the valid one on the SD card before application), they bypassed signature verification. This allowed them to patch the Gateway's bootloader, disable its software secure boot, and execute arbitrary code on the Gateway's NXP PowerPC SOC running FreeRTOS (Stage 4).

These findings collectively represent a severe compromise, demonstrating how an attacker could move from a remote, unauthenticated entry point to gaining full control over critical vehicle components, including the ability to send arbitrary CAN messages.

Technical Deep Dive

▶ Watch: Live Demo: Bluetooth RCE to Kernel Root (27:00)

The exploit chain developed by Synacktiv is a masterclass in chaining multiple vulnerabilities across different layers of the Tesla system.

Initial Compromise: Bluetooth RCE in BServer

The journey began by targeting the Bluetooth stack, specifically Tesla's custom BServer application. This binary was identified as a prime target because it handles numerous Bluetooth protocols and, critically, was compiled without Position Independent Executable (PIE). This meant that memory addresses within BServer were static and predictable across reboots, greatly simplifying exploitation. BServer also used a custom memory allocator, which can sometimes introduce unique exploitation primitives.

The specific vulnerability was a heap overflow located in the BipImageParsing function, responsible for parsing XML files related to Bluetooth image exchange (e.g., album art). The Object Exchange Protocol (OBEX) is used for this functionality, along with Service Discovery Protocol (SDP) and Audio/Video Remote Control Profile (AVRCP) for other audio features. The XML structure, as defined by the standard, allows for attachment tags, which can be present multiple times. The BipImageParsing function had an internal buffer limit of 48 attachments, but the XML parser itself had no such limit. If an attacker sent an XML file specifying more than 48 attachments, the parser would attempt to write control data beyond the allocated buffer, leading to a heap overflow.

This heap overflow, combined with the predictable memory layout due to the lack of PIE, allowed the attackers to achieve an arbitrary global write primitive. By carefully crafting the overflow, they could overwrite metadata of adjacent heap allocations, specifically targeting a global variable (g_pr_variable) that stored an application timer's address. Overwriting this address with a pointer to their Stage One shellcode allowed them to hijack control flow and execute arbitrary code within the BServer process.

Sandbox Escape and Wi-Fi Firmware Code Execution

Even with code execution in BServer, the process was heavily sandboxed. Tesla implemented seccomp for syscall filtering, AppArmor for access control to files, and mini-jail for network namespace isolation, restricting BServer to expected Bluetooth functionalities. However, BServer legitimately communicates with the physical Bluetooth chip using the Host Controller Interface (HCI) protocol over a UART interface. This communication involves sending and receiving HCI packets, including vendor commands used for loading Bluetooth firmware.

The researchers discovered that at least two of these vendor commands allowed writing to the Bluetooth chipset's internal memory. Crucially, the Bluetooth and Wi-Fi functionalities are often integrated into a single combo chip (e.g., Broadcom BCM4354). This chip shares internal RAM between its Bluetooth and Wi-Fi components. Specifically, the RAM dedicated to Wi-Fi firmware is memory-mapped and directly writable from the Bluetooth part of the chip using the vendor commands.

This critical architectural oversight meant that BServer, despite its sandbox, could write directly into the Wi-Fi RAM memory. During system boot, the Wi-Fi firmware is loaded into this RAM and executed. By patching this firmware in memory, the attackers could inject their Stage Two shellcode and gain code execution on the Wi-Fi chipset, which runs on an ARM core. The patch involved injecting their code into an unused memory range and then modifying the Wi-Fi operating system's idle task to jump to their injected code, thus achieving persistent execution within the Wi-Fi firmware.

Privilege Escalation: Linux Kernel LPE from Wi-Fi Chipset

The Wi-Fi chipset, now under attacker control, offered a far more potent attack surface. It connects to the main infotainment processor via PCI Express (PCIe) and communicates using DMA (Direct Memory Access) and mailboxes, leveraging a complex Linux driver called bcmdhd. While IOMMU (Input/Output Memory Management Unit) was in place to restrict DMA access, the interaction between the firmware and the driver still presented opportunities.

Firmware and driver communicate by sharing information through specific structures. These structures are copied from the chipset memory by the driver during startup, and the firmware can modify them and request the driver to reload them via a special mailbox command. The vulnerability lay in the driver's handling of these shared structures: one of the offsets within a structure was used to point to a memory zone inside the chipset memory without being checked.

This allowed the Stage Two Wi-Fi firmware to craft a malicious structure, using the unchecked offset to write after the legitimate mapped zone in the kernel's vmalloc region. To achieve Local Privilege Escalation (LPE), the attackers needed a reliable target for this arbitrary write. They chose process kernel stacks. They performed a kernel stack spray by forking multiple times from a Stage One child process (still running in BServer's context, but now able to launch arbitrary programs thanks to Stage Two). These child processes were then blocked in kernel mode using a blocking syscall like clock_nanosleep, ensuring their kernel stacks remained active and in a predictable state.

A key factor in making this reliable was the GPU driver, which allocates a large buffer, fixing the offset between the Wi-Fi mapping and the GPU mapping. This, in turn, fixed the offset to the sprayed kernel stacks. To bypass Kernel ASLR, the attackers used a cache channel attack, similar to methods described in a blog post about entry_describe. This allowed them to leak the ASLR base address with high reliability.

With ASLR bypassed and a target kernel stack identified, the Stage Two Wi-Fi firmware used the driver vulnerability to write a ROP chain into one of the sprayed kernel stacks. This ROP chain involved two stages:

1. The first stage, executed when clock_nanosleep was unblocked, used a gadget to copy more data (a larger ROP chain) from user space into the kernel stack using the copy_from_user function.
2. The second, larger ROP chain then patched the power_off command string in kernel data with a desired shell command (e.g., to launch their Stage Three root shell), and called the do_off_work function to execute it. Finally, do_exit was called to gracefully terminate the process. This granted them unrestricted root access on the infotainment system.

Security Gateway Compromise

The final objective was to compromise the Security Gateway, an MCU (NXP PowerPC SOC) running FreeRTOS. The Gateway is critical: it filters CAN messages, provides sensitive vehicle information (VIN, autopilot status), and updates other ECUs. It has no hardware-based secure boot but uses a software secure boot implemented in its bootloader.

The attackers found a logic bug in the Gateway's updater mode. The update process involves the infotainment system fetching ECU firmware via TFTP and saving it to the Gateway's SD card. The Gateway then reboots into updater mode, loads the binary from the SD card, checks its signature, and executes it. The critical flaw was that the updater could fetch multiple files.

The exploit involved a race condition:

1. The infotainment system instructs the Gateway's updater to fetch a valid firmware file via TFTP. The Gateway downloads it, verifies the signature, and schedules the update.
2. Immediately after, the infotainment system instructs the Gateway to fetch an invalid firmware file via TFTP, but with the same filename. This invalid file overwrites the previously valid file on the SD card.
3. Because the signature verification was only performed during the fetch phase, not during the application phase, the Gateway proceeds to apply the now-invalid firmware from the SD card.

This bypasses the signature check, allowing the attackers to apply arbitrary updates. They used this to patch the Gateway's original bootloader, removing its software secure boot implementation. With the secure boot disabled, they could then boot an arbitrary updater binary, injecting their Stage Four shellcode into a modified version of the original updater. This allowed them to leverage existing functions within the Gateway firmware, such as can_write, to send arbitrary CAN messages to other ECUs, achieving full control over the vehicle's internal network.

Demo / Proof of Concept

▶ Watch: Security Gateway: Logic Bug for Firmware Signature Bypass (33:00)

The speakers provided a live demonstration of the first two stages of their exploit chain: the Bluetooth RCE and the kernel LPE, leading to root on the infotainment system. An actual Tesla Model 3 infotainment ECU was placed on the table, powered and connected to a display.

David Berard launched the exploit from a laptop. The process began with the laptop connecting to the ECU via Bluetooth. The bluetoothctl utility showed the device connecting, and the AVRCP protocol indicated a music playback request. Although nothing was immediately visible on the infotainment screen, the BServer process did not crash, indicating successful exploitation of the heap overflow.

After a brief moment, the screen on the ECU displayed a custom image. This visual confirmation served as the Proof of Concept for the successful execution of their Stage Two and Stage Three exploits. Displaying an image on the screen demonstrated not only that they had achieved code execution on the Wi-Fi chipset and then root privileges on the infotainment system, but also that they had successfully escaped the stringent sandboxing restrictions initially imposed on the BServer process. The ability to display a custom image from a rooted, unconstrained process directly proved the efficacy of their kernel LPE.

Defensive Implications

▶ Watch: Q&A: Real-World Tesla Exploitation Capabilities (41:00)

The detailed exploit chain uncovered by Synacktiv provides critical insights for Tesla and other automotive manufacturers to enhance their security posture. Tesla, in response to these findings, has already implemented several significant fixes:

1. PIE for BServer: The BServer binary, a cornerstone of the initial Bluetooth RCE, is now compiled as a Position Independent Executable (PIE). This eliminates the predictability of memory addresses, making heap overflows significantly harder to exploit reliably.
2. Bluetooth Vulnerability Patch: The specific heap overflow in the BipImageParsing function related to OBEX image parsing has been patched, preventing the initial entry point of the attack.
3. bcmdhd Driver Patch: The vulnerability in the bcmdhd Wi-Fi driver, which allowed writing past mapped memory regions, has been addressed, mitigating the kernel LPE vector from the Wi-Fi chipset.
4. Security Gateway Hardening: Improvements to the Security Gateway's update mechanism have been implemented. This includes signing the manifest file (which describes the update), preventing the simple overwrite of a valid file with an invalid one. Additionally, temporary files created during the update process are now removed if signature verification fails, preventing the logic bug that allowed the signature bypass.

Beyond these specific patches, the research highlights broader defensive implications:

• Strict Input Validation: The Bluetooth heap overflow stemmed from insufficient validation of XML input. All external inputs, especially those parsed in low-level components, must undergo rigorous validation to prevent buffer overflows and other memory corruption bugs.
• Comprehensive Sandboxing: While BServer was sandboxed, the ability to escape it through hardware interaction (Wi-Fi/Bluetooth shared memory) demonstrates that sandboxing needs to consider the full attack surface, including device drivers and shared hardware resources.
• Secure Boot and Update Mechanisms: The Gateway's logic bug in its updater mode underscores the need for robust, end-to-end secure update processes. Signature verification must be performed at every critical stage (download, storage, and application) and temporary files handled securely. Hardware-based secure boot mechanisms are preferable to software-only solutions.
• Memory Safety Best Practices: Compiling binaries with PIE, ASLR (Address Space Layout Randomization), and DEP (Data Execution Prevention) should be standard practice across all critical components to raise the bar for exploitation.
• Least Privilege Principle: Processes should only have the minimum necessary privileges and access to hardware resources. The shared RAM between Wi-Fi and Bluetooth, accessible via BServer's vendor commands, was a critical point of failure.
• Thorough Architectural Review: The multi-stage nature of this attack, chaining vulnerabilities across different architectural layers, emphasizes the need for holistic security reviews that consider inter-component interactions and potential pivot points.

Key Takeaways

• Multi-Stage Attacks are Potent: This research demonstrates that even seemingly minor vulnerabilities can be chained together across multiple system layers (Bluetooth stack, Wi-Fi firmware, Linux kernel, Security Gateway) to achieve a complete system compromise.
• Importance of Secure Coding Practices: The initial Bluetooth RCE was a classic heap overflow due to insufficient input validation, and the kernel LPE leveraged an unchecked offset. Adherence to memory-safe coding and rigorous input validation is paramount.
• Architectural Flaws Create Attack Vectors: The shared RAM between Bluetooth and Wi-Fi within a combo chip, and the lack of PIE for a critical service, exposed significant architectural weaknesses that were exploited.
• Secure Update Mechanisms are Critical: The logic bug in the Security Gateway's updater highlights that even if components are signed, flaws in the update workflow can bypass security checks, allowing arbitrary code execution on critical ECUs.
• Pwn2Own Drives Security Improvements: Competitions like Pwn2Own incentivize deep research into complex targets, leading to the discovery of high-impact vulnerabilities and ultimately contributing to significant security hardening by vendors like Tesla.
• Collaboration with Vendors is Key: The speakers acknowledged Tesla's support, providing updated ECUs and firmware, which facilitated the research and allowed for timely patching, demonstrating the value of responsible disclosure and vendor collaboration.

About the Speaker(s)

David Berard and Vincent Dehors are both members of the reverse engineering team at Synacktiv. They specialize in low-level security and frequently conduct assessments on embedded systems. Their work often involves participating in offensive security competitions like Pwn2Own, organized by the Zero Day Initiative (ZDI), where contestants aim to achieve arbitrary code execution on target systems. They have a strong track record of researching Tesla vehicles, having previously found critical vulnerabilities in 2022. Their expertise lies in identifying and exploiting complex vulnerabilities across diverse software and hardware components in automotive and other embedded systems.