By Omar Yang (Senior Threat Researcher, Automotive)
At Pwn2Own Vancouver 2024, security researchers from Synacktiv discovered a vulnerability in the Tesla Model 3 that could enable malicious attackers to execute arbitrary code.
The attack chain begins with the tire pressure monitoring system (TPMS), where a vulnerability in the setup process can lead to an out-of-bounds write. This flaw allows attackers to take over a critical electronic control unit (ECU) responsible for various vehicle functions. Compounding the issue, a TPMS feature intended to optimize tire wear enables this vulnerability to be exploited without user interaction — hence a zero-click attack.
Understanding Tesla’s TPMS
Tesla’s TPMS is designed to detect abnormalities in tire pressure, enhancing road safety. The system relies on sensors embedded in the tires to wirelessly transmit real-time data. While older Tesla models used sub-GHz radio frequencies, newer generations have adopted Bluetooth-enabled sensors for improved communication.
At the receiving end, Tesla employs a module known as the vehicle controller secondary (VCSEC) ECU. This system-on-chip (SoC) not only manages TPMS data but also processes communications from the mobile app and NFC. The VCSEC controls critical functions such as door locks and vehicle startup. It also interfaces with the vehicle’s bus to relay messages across various modules.
To establish secure communication, a handshake is required before the VCSEC and the TPMS sensors can exchange data. This process involves certificate-based authentication to verify the sensors’ legitimacy. Ironically, a vulnerability was discovered within this very mechanism intended to bolster security.
Vulnerability during TPMS sensor enrollment
During the communication setup, the VCSEC requests an X.509 certificate from the TPMS. The exchanged data includes a startIndex field, which specifies the starting point of the data structure. Ideally, the startIndex is an unsigned integer starting from 0. However, the Synacktiv researchers discovered that the system does not properly validate this field. By inputting a negative value, they exploited the flaw to trigger an out-of-bounds write, ultimately enabling arbitrary code execution.
Another contributing factor to this vulnerability is the absence of proper memory protection within the system. Modern protection mechanisms, such as address space layout randomization (ASLR) and memory management/protection units (MMUs/MPUs), which are commonly used in computers and smartphones, are not implemented. These mechanisms could have significantly reduced the likelihood of a successful attack.
Zero-click hack via TPMS auto learn
In Tesla vehicles, the front and rear tires wear at different rates because, in dual-motor models, only the rear wheels are powered by the motors. Although the front and rear tires are the same size, Tesla recommends regular tire rotation to promote even wear and extend tire life.
To accommodate tire rotation, the TPMS sensors transmit rear tire readings as though they were from the front without undergoing reconfiguration. Furthermore, the TPMS might fail to send readings if a new sensor is installed. To address this, Tesla has implemented a feature called “auto learn,” which automatically detects TPMS sensors after the car runs for over 90 seconds and reaches a speed of at least 25 kph.
This auto learn mechanism, however, introduces a pathway for attackers to exploit the aforementioned vulnerability in the TPMS sensor enrollment process. When a Tesla vehicle meets the criteria for auto learn, the VCSEC and TPMS attempt to resynchronize, creating an opportunity for malicious actors to impersonate either the VCSEC or the TPMS sensors. An attacker could use a development board to mimic the VCSEC, preventing the TPMS sensor from communicating with the legitimate VCSEC. The attacker could simultaneously use another development board to impersonate a TPMS sensor, exploiting the vulnerability.
By combining the vulnerability in the TPMS sensor enrollment process with the auto learn feature, an attacker can achieve remote code execution (RCE) — all without requiring user interaction.
Security implications
The VCSEC module plays an important role in managing vehicle access, including granting users permission to start the car and interfacing with the vehicle’s Controller Area Network (CAN) bus. If the TPMS vulnerability is exploited, attackers could inject or drop malicious CAN messages, potentially leading to car theft or unauthorized control over critical vehicle functions.
This vulnerability arises from a lack of validation in specific fields, but it does not automatically guarantee a successful exploit. Modern memory protection mechanisms, if implemented, could have interrupted the attack chain. However, Tesla’s VCSEC module uses a memory configuration marked as readable (R), writable (W), and executable (X) — a configuration that makes exploitation easier. Typically, memory sections are designed to avoid being both writable and executable at the same time. For instance, the code section is marked readable (R) and executable (RX), while the data section is both readable (R) and writable (RW). When a memory section is both writable and executable, attackers can inject and execute malicious code, bypassing critical security safeguards.
The Zero Day Initiative (ZDI), the organizer of Pwn2Own Vancouver and VicOne’s co-host for Pwn2Own Automotive and partner in vulnerability discovery and disclosure, promptly reported this bug to Tesla. In their presentation at Hexacon 2024, the researchers from Synacktiv confirmed that Tesla responded swiftly by releasing a firmware update to fix the vulnerability and checked other variables and related systems for similar issues.
A background on responsible disclosure timelines
Most might wonder why there is often a delay from the time the ZDI announces that a team has successfully hacked or “pwned” a device or software at Pwn2Own events until the subsequent publication of the techniques used in the hacks. This delay is part of the coordinated vulnerability disclosure (CVD) process, which is designed to manage zero-day vulnerabilities more responsibly.
In the 1990s, only a few hackers actively hunted for vulnerabilities, and many vendors were unprepared to handle them. Both white hat hackers and vendors had concerns, such as, “Are hackers submitting vulnerabilities in exchange for benefits?” or “Will the vulnerabilities be fixed, or will the submission be a waste of time?” It came to this compromise: Hackers first submit the vulnerabilities to the vendors, who then release a patch and publicly acknowledge the hackers for their discovery.According to the ZDI’s disclosure policy, a submitted vulnerability is disclosed once a patch is available or after a certain period if the vendor is unresponsive. This approach prevents or lowers the risk of vulnerability exploitation by either resolving the issue or making the public aware of a threat that has no known fix. This explains the time gap between the initial submission of vulnerabilities and the detailed disclosure.
