1Unlocking the Drive
Exploiting Tesla Model 3

Who are weDavid BERARDSECURITY EXPERT@_p0ly_2

Offensive security
150 Experts
Pentest, Reverse Engineering, Development,Incident Response

Vincent DEHORSSECURITY EXPERT@vdehors

Reverse Engineering team
45 reversers
Low level research, reverse Engineering,vulnerability research, exploit development, etc.

Pwn2own& previous work

Competition organized by ZDI

Took place in Vancouver (April 2023)
New Pwn2Own Automotive in Tokyo (Jan. 2024)
Pwn2Own 2022
Infotainment preauth RCE (Wifi)& sandbox escape & 2 kernel bugs3

Pwn2own 2023

4Timeline

GTW

Bluetooth

Exploit

Vulnerabilities& exploit

Vulnerabilities

A uselessservice

Dec 2022

Mid Feb 2023

8 mar 2023

BluetoothBluetoothVulnerability
research

Finalize
exploit

Mid Jan 2023

6 mar 2023

PC diedP2O

on the plane
Buy a new one
in Vancouver
20 mar 2023

Event
22-23 mar 2023

LPE

ExploitStart LPE
research

Stabilisation& chaining

13 mar 2023

20-23 mar 2023

Car architecture

5

Multimedia and vehicule domains separared by a gateway

Multimedia domain

Vehicle domain
Actuators
ECU 1

ECU 2Sensors

Infotainment

CAN 1SecurityGateway

CAN NActuators

ECU 3Connectivity
components

Sensors

Model 3 – Infotainment

6Hardware

Gateway: SPC5748GS

SoC Intel Atom or AMD Rizen

WiFi/BTCANs

Hardware setupLab• Multiple Infotainment ECU• Some from Ebay
• 2 provided by Tesla• After pwn2own 2022, Tesla gave us SSH keys toaccess our units

7Exploit chain

8

Chaining three exploits for a remote-to-CAN fullchain

Infotainment

Security Gateway

13

bsa_server process
Firmwares updateapp

Linux Userland

2Attacker’sPC

BCMDHD driverLinux Kernel

Bluetooth FirmwareWiFi Firmware

WIFI/BT CHIP BCM4359

Bluetooth features
Why does the car need Bluetooth ?

Message and contact synchro.
Display received messages on the infotainment
screen

Voice call
Display received SMS on the infotainment screen

Play music
Play music from a phone using Bluetooth standards(supported by smartphones)

Spotify
Play music from a phone using Spotify

9Bluetooth classic
A huge attack surface

SPP

GATT

MAP

AVRCP SDPPAN AVDTP
HID
L2CAP
SYNC
RFCOMMDUN
OBEX
HCI
BNEP HFPFTP

All these acronyms are real
Bluetooth protocols / profiles
And there are much more…

10Bluetooth classic
Attack surface on Tesla car

Profiles for Audio Playback
PROFILES

Service Discovery (SDP)
Retrieves the service list provided by the peer

OBEXSDP

RFCOMM

Advanced Audio Distribution Profile (A2DP)
Protocol for audio streaming

L2CAP

Audio/Video Remote Control Profile (AVRCP)
HCI
Hardware / RF

Audio controls (play/stop, playlist management, …)

Basic Imaging (BIP)
Allows to transfer the Cover Art image

11

Bluetooth stack

12

Implementation in the infotainment

Infotainment kernel

Wifi / BT
Chip

UART

UARTsubsystem

Infotainment userland

TTYchardev

bsa_server

UNIXbtd

HCIWhole Bluetooth stack

DBUS

Qtcarbluetoothbsa-server

13

Custom Bluetooth stack

Big attack surface
A lot of bluetooth features are managed by this program

Natural target for an attacker
Looks like an exception in this heavily hardened system

High probability of vulnerability
Closed source vendor code written in C
Custom allocator

Bad hardening
Binary compiled without PIE

Debug symbols
Similar binary with debug symbols found on Github

Sandboxes
The process is still well sandboxedVulnerability research

14

Usual Workflow for Vulnerability research

Remote GDB on physical ECU

Researcher’s laptopSSHInfotainment

gdb + pwndbg

TCP

gdb-server

Modified BluezBluetoothbsa_server

Static analysis

Dynamic instrumentation• Reverse engineering with Ghidra / IDA• Attacker device is a laptop with a standard bluetooth chip

• Help of debug symbols from another binary• Bluez recompiled to add our exploit code

• Tesla Infotainment with SSH access and gdb

BIP

15

Reaching the BIP surface

1

Playback is configured by the phone (AVRC)OBEX GET x-bt/img-img<image-descriptor version=‘1.0’>…</image-descriptor>

2The car queries available Cover Art pictures using
OBEX protocol

3

The phone send available images description using
OBEX protocol

4

The car downloads and displays one image

OBEX Response<?xml version='1.0' encoding='utf-8' standalone='yes' ?><image-properties>...
</image-properties>

Vulnerability in BIP
OOB Write

Heap buffer overflow in the BIP protocol implementation▪ In the BIP parsing function (bip_xp_parse)▪ Parsing result is stored in an allocation of 0x2800 bytes containing an array of images metadata▪ Adding an « attachment » fills 0x100 bytes, 38 are enough to overflow (limit is 256, due to a bug)▪ Allows writing controlled bytes after the end of an allocation (custom allocator)<?xml version='1.0' encoding='utf-8' standalone='yes' ?><image-properties><attachment /><attachment /><attachment />...
<attachment name=“AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" /></image-properties>

16

Heap exploitation17

Bsa-server custom heap🤯

Custom heap management from a code base called GKI▪ Allocations located in arrays in the data section (no PIE = no ASLR)▪ Very few corruption checks compared to the glibc

p_nextp_nextp_firstidtidsttype< chunk data >ddbaddba

idtidsttype< chunk data >ddbaddba

Arbitrarywrite

Code execution

18

Taking over a timer, again…

Arbitrarywrite

Main loop

Application
timer queue

Arbitrary
CallFake timer

All addresses are located in the binary (globals, gadgets)so they are already known

Stack Pivot

Injected C program (stage1)

ROP

Shellcode(Small)The end ?

19

What can we do with this code execution ?

• Dedicated UIDKafel• No useful capability• Syscalls filtering• No network

AppArmor• All sandboxes activatedprocess
bsa_server• But two legitimate APIs
• TTY communication• One UNIX socket tocommunicate with btd➢ Limited attack surface• Whitelist for file access• Cannot execute anything

Minijail• Dedicated chroot• Empty network stack

LPE

20

Arbitrary write inside the chipset firmware

Infotainment

bsa_server process• bsa_server communicates with Bluetooth
chipset through HCI protocol• Vendor specific commands are used toinitialize the chipset (i.e. load Bluetooth
firmware patches)Stage1 payload
Linux Userland

HCI

BCMDHD driver• At least HCI_BRCM_WRITE_RAM and
HCI_BRCM_SUPER_PEEK_POKE
commands allow arbitrary writting to theinternal chipset memory

Linux Kernel• So stage1 injected in bsa_server can write
inside the chipset memory
Bluetooth Firmware

WiFi Firmware

WIFI/BT CHIP BCM4359

LPE

21

Gaining code execution inside the WiFi chipset

Infotainment

bsa_server process• Bluetooth firmware and WiFi firmware sharesome memory regions• WiFi firmware RAM code is mapped ataddress 0x500000 in the Bluetooth part

Stage1 payload
Linux Userland• HCI_BRCM_WRITE_RAM HCI command
allows writing to the WiFi firmware RAM code

HCI• WiFi firmware runs on an ARM core
BCMDHD driver• So stage1 injected in bsa_server can patch
WiFi firmware to inject custom code

Linux Kernel

Bluetooth Firmware

WiFi Firmware

Stage2 payload
Sharedmemory
WIFI/BTCHIP BCM4359• WiFi Firmware Idle task is patched to jump on
the injected code: stage2

LPE

Code execution inside the WiFi chipset

Stage1 WiFi code injector

Patched WiFi Firmware idle_thread to jump in stage222

LPE

23

Attack surface from the chipset

Infotainment• WiFi part of the chipset uses PCIe tocommunicate with the main processor- DMA- Mailbox

bsa_server process
Stage1 payload• WiFi is managed by the BCMDHD Linux driverLinux Userland• Stage2 in the WiFi firmware is well placed toattack the Linux driver

BCMDHD driverLinux Kernel

PCIe

Bluetooth Firmware

Stage2 payload
WiFi Firmware

WIFI/BT CHIP BCM4359

LPE

Bcmdhd to chipset memory structures• Some structures are shared between chipset anddriver, like pciedev_shared_t / ring_info_t• These structures are reloaded from the chipset
memory while handling a mailbox interrupt- In normal operation: during chipset startup, andchipset software crash• Stage2 can generate the mailbox interrupt to fill thestructure ring_info_t

24

LPE

25

Out-of-bound write in bcmdhd• d2h_r_idx_ptr is used as an offset to write inside a ioremap region (TCM)• The offset is not checked to be in the TCM region!
• Ioremap places addresses in the vmalloc region• Stage2 can write out of bound after the ioremap TCM region by setting d2h_r_idx_ptr to a value bigger
than the TCM size
• Need to find something to write on!

TCM ioremap bufferwrite

LPE

26

Out-of-bound write exploitation• Process Kernel Stacks are good candidates- Are in vmalloc region (allocated in _do_fork function)- Can be sprayed from Stage1 by forking process multiple times- Process children can be blocked in a syscall to stay in Kernel (i.e. clock_nanosleep)- Write to Process Kernel Stacks is a powerful primitive => direct ROP after unblocking syscall• Thanks to a big buffer allocated by the GPU driver, the offset (from TCM) of a process kernel stack is fixed• Stage2 (payload in WiFi firmware) can patch a process kernel stack of a child of Stage1 (payload inbsa_server) blocked in clock_nanosleep
Fixed offset
do_fork

do_fork

do_fork

do_fork

do_fork

write

do_fork

do_forki915_ggtt_init_hw

do_fork

do_fork

do_fork

do_fork

do_fork

do_fork

do_fork

do_fork

do_fork

do_fork

do_fork

0x20007000

do_fork

TCM ioremap buffer

KASLR bypass

27& hardened kernel configuration Random kernel base address
But not a lot of possibilities…
0xffffffff81000000
0xffffffff82000000
0xffffffff83000000...
0xffffffffbf000000

Similar side-channel issue
Prefetch times differ

Reading a nice blogpost on sidechannels at the same time…

https://www.willsroot.io/2022/12/entrybleed.html

ffffffffb0900000 179
ffffffffb0a00000 138
ffffffffb0b00000 136
ffffffffb0c00000 44…
ffffffffb1300000 179

🤔

LPE

28

ROP chain

Strategy
End of a kernel process stack
0xffffc90024007f50 │ 75 00 a0 81 ff ff ff ff 44 44 44 44 44 44 44 44 │0xffffc90024007f60 │ 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 │0xffffc90024007f70 │ 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 │0xffffc90024007f80 │ 44 44 44 44 44 44 44 44 42 02 00 00 00 00 00 00 │0xffffc90024007f90 │ 00 00 00 00 00 00 00 00 44 44 44 44 44 44 44 44 │0xffffc90024007fa0 │ 44 44 44 44 44 44 44 44 da ff ff ff ff ff ff ff │0xffffc90024007fb0 │ b1 d2 23 92 c0 55 00 00 c0 ed 63 db ff 7f 00 00 │0xffffc90024007fc0 │ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │0xffffc90024007fd0 │ e6 00 00 00 00 00 00 00 b1 d2 23 92 c0 55 00 00 │0xffffc90024007fe0 │ 33 00 00 00 00 00 00 00 42 02 00 00 00 00 00 00 │0xffffc90024007ff0 │ 80 ec 63 db ff 7f 00 00 2b 00 00 00 00 00 00 00 │Last return address
Some controllable saved task registers (used to restore register values)

Pivot
1. Replace Return address by a RET gadget address(that is executed when the clock_nanosleep
syscall ends)
2. Use saved register as a first ROP chain
Ropchain 1 (in saved registers)
1. Jump in copy_from_user to fill the Kernel process
stack with a second ROP chain
Ropchain 2
1. Jump in copy_from_user to override poweroff_cmd
string in the kernel memory with the command wewant to start
2. Call poweroff_work_func to start the command as
root with User Mode Helper Linux subsystem
3. Call do_exit to end the task properly

LPE

29

root code execution

Infotainment

bsa_server process

Stage3
Executed as root
from the kernel

Stage1 payload

Linux Userland

BCMDHD driverLinux Kernel

Bluetooth Firmware

Stage2 payload
WiFi Firmware

WIFI/BT CHIP BCM4359

LPE

30

root code execution

Infotainment

bsa_server process

Stage3
Executed as root
from the kernel

Stage1 payload

Linux Userland

BCMDHD driverLinux Kernel

Bluetooth Firmware

Stage2 payload
WiFi Firmware

WIFI/BT CHIP BCM4359

Security Gateway

ETHERNETGTW

31

Security Gateway architecture

SYSTEM

NETWORKS

Features

Same PCB as Infotainment—SoC NXP MCP5748G—
FreeRTOS PPC-VLE—
No hardware based secure-boot—Uses its own internal flash for software

Ethernet—
CAN buses (Chassis/Party/Vehicle)

Filter CAN messages—
Save log files—Update mode
Update other ECUs and itself—Provide sensitive information to otherECU(VIN/Serial/…)—Config Ethernet switch

GTWSecurity Gateway software & attack surface• 3 main software parts- Bootloader- Selects between the two following modes and do software secure boot- Update mode
- Fetches updates on the infotainment through TFTP
- Checks them and updates ECUs through CAN- Main App mode
- Handles CAN over UDP messages and filters them
- Provides access to some sensitive values (VIN, autopilot subscriptionsetc..)- Acts as a log server

32

GTW

Security Gateway exploit• GTW uses fixed addresses (no ASLR, code is in the internal flash)• Seems to be greatly audited, and safely developed• Logic TOCTOU bug inside the update mode => 100% stable

33

GTW

34

Booting the update mode

Infotainment

Security Gateway
SDCARDXFER UPDATE.IMG

TCP xfer (port 1050)

REBOOT_FOR_UPDATEUDP_API (port 3500)

Firmware mainApp(ROM)Write on SDCARDREBOOT

Bootloader(ROM)
Load & Boot

Update mode(RAM)Read & verifysignature

GTW35

Update mode interactions

Infotainment

TFTP Server

Security Gateway

Update mode
(RAM)
Phase 1SDCARD
Write on SDCARD

Fetch & verify

Update mode
(RAM)
Phase 2

Read

Apply without verify

Internal ROM

CAN

WRITE/deploy

Temp files(ECU_ID)

ECUs

GTW

36

Update mode two phase mode

Infotainment

Security Gateway

TFTP Server
FETCH 1

FETCH 2

FETCH 3Update mode
(RAM)
Phase 1
Fetch & verify

FETCH 4/deploy

APPLY 1

Update mode
(RAM)
Phase 2APPLY 2

Apply without verify
APPLY 3APPLY 4

GTW37

BUG• Update mode can be forced to fetch two times the same ECU update• The first time if the file has a good signature the update is scheduled to beapplied, and the file is saved on the SDCARD• The second fetch overrides the file on the SDCARD, if the signature is invalid
the first one is still scheduled, and the bad temporary file is not removed• When applying updates, the signature is not re-checked, so the badly signed fileis applied• This bypasses the signature check, and allows an attacker to apply arbitrary
updates, and can be used to gain code execution on the security gatewayGTW38

Secure boot

Security Gateway• Bootloader verifies next stages

Bootloader(ROM)
SDCARD / FAT32
driverTFTP client• Hardware (NXP chip) doesn’t provide
secure boot, bootloader in the internal
flash is never verified
Internal FlashED25519 Signature verification• Gateway update mode allows to update
its own firmware, including thebootloader• Signature bypass in update mode =>code exec in bootloader
Update mode
(sdcard -> RAM)

Update mode
(TFTP -> RAM)App Mode(ROM)GTW39Secure boot

Security Gateway• Bootloader patch

Bootloader(ROM)
SDCARD / FAT32driver

TFTP client• Remove ED25519 signature check

Internal FlashED25519 Signature verification

Update mode
(sdcard -> RAM)

Update mode
(TFTP -> RAM)App Mode(ROM)• Use Update mode boot mechanism toboot on a controlled firmware• Controlled firmware has unrestricted
access to the CAN vehicle & chassis
busesAccess to CAN busses

40

From remote to CAN

Infotainment

bsa_server process

Stage3
Executed as root
from the kernel

Stage1 payload

Linux Userland

BCMDHD driverLinux Kernel

Bluetooth Firmware

Stage2 payload
WiFi Firmware

WIFI/BT CHIP BCM4359

Security Gateway

ETHERNET

Stage4
Custom firmware

CANECUs

FixesTesla Response• bsa_server is now a PIE binary and the vulnerability has beenpatched• Bcmdhd vulnerability is patched• Security GTW• Now moves files with a specific name when signature iscorrect• Manifest is now signed• If a signature check fails, the file is deleted for the SDcard

41

Pwn2Own 2023

Synacktiv was Master Of Pwn for the second time with many entries(Windows/macOS/Ubuntu/VirtualBox/Tesla)

First Tier 2 entry ever (could have been a Tier 1 but we had chosento split RCE+LPE and Gateway entries)

42

Conclusion
Not so long of a work
Strong knowledge of the Tesla cars architecture (Pwn2Own 2022)
Hardware and debug facilities

Not well hardened binary
Great support from Tesla
Tesla provided us an ECU that can receive updates

ZDI and Tesla gave us updates
Version freeze 1 month before the event
Thanks to themWas fun
We won a car for our future research ☺

43

44

www.linkedin.com/company/synacktiv

www.twitter.com/synacktiv

www.synacktiv.com