Hackers can exploit critical vulnerabilities in Mazda’s infotainment system, including one that enables code execution via USB, compromising your car’s security and putting you at risk.
Cybersecurity researchers at ZDI (Zero Day Initiative) have identified several critical vulnerabilities in Mazda‘s infotainment systems, specifically in the Connectivity Master Unit (CMU) installed in multiple Mazda car models, including the Mazda 3 from the years 2014 to 2021.
These vulnerabilities, caused by “insufficient sanitization” when handling attacker-supplied input, could allow a physically present attacker to exploit them by connecting a specially crafted USB device to the target system. Successful exploitation could result in arbitrary code execution with root privileges.
The Target
The CMU unit, manufactured by Visteon Corporation, an anutomotive technology company, and initially developed by Johnson Controls Inc (JCI), runs on the latest available software version (74.00.324A). However, earlier software versions down to at least 70.x may also be affected by these vulnerabilities. The CMU is part of an active “modding scene” where users release software tweaks to alter the unit’s operation, often exploiting such vulnerabilities.
The Vulnerabilities
There are multiple vulnerabilities identified in the CMU system. The details of each are as follows:
- SQL Injection (CVE-2024-8355/ZDI-24-1208): An attacker can inject malicious SQL code by spoofing the iAP serial number of an Apple device. This allows the attacker to manipulate the database, disclose information, create arbitrary files, and potentially execute code.
- OS Command Injection (CVE-2024-8359/ZDI-24-1191): The REFLASH_DDU_FindFile function in the libjcireflashua.so shared object fails to sanitize user input, allowing an attacker to inject arbitrary OS commands that can be executed by the head unit OS shell.
- OS Command Injection (CVE-2024-8360/ZDI-24-1192): The REFLASH_DDU_ExtractFile function in the libjcireflashua. so shared object also fails to sanitize user input, allowing an attacker to inject arbitrary OS commands that can be executed by the head unit OS shell.
- Missing Root of Trust in Hardware (CVE-2024-8357/ZDI-24-1189): The application SoC is missing any authentication of the bootstrap code, allowing an attacker to manipulate the root filesystem, configuration data, and potentially the bootstrap code itself.
- Unsigned Code (CVE-2024-8356/ZDI-24-1188): The VIP MCU can be updated with unsigned code, allowing an attacker to pivot from a compromised application SoC running Linux to the VIP MCU and gain direct access to the connected CAN busses of the vehicle.
Exploitation
An attacker can exploit these vulnerabilities by creating a file on a FAT32-formatted USB mass storage device with a name that contains the OS commands to be executed. The filename must end with .up for it to be recognized by the software update handling code.
Once the initial compromise is achieved, the attacker can gain persistence through manipulation of the root file system or install a specially crafted VIP microcontroller software allowing unrestricted access to vehicle networks.
Associated Risks
According to ZDI’s blog post, the attack chain can be completed in a few minutes in a lab environment, and there is no reason to believe it will take significantly more time against a unit installed in a car.
This means that the vehicle can be compromised while being handled by a valet, during a rideshare, or via USB malware. The CMU can then be compromised and “enhanced” to attempt to compromise any connected device in targeted attacks that can result in DoS, bricking, ransomware, safety compromise, etc. The worst part of it is that these security vulnerabilities remain unpatched.
“This research effort and its output highlighted the fact that high-impact vulnerabilities can be found even in a very mature automotive product that has been on the market for a number of years and with a long history of security fixes. To date, these vulnerabilities remain unpatched by the vendor.”
ZDI analyst Dmitry Janushkevich
Conclusion
The discovery of these vulnerabilities shows the importance of considering the whole system’s security and security-testing complete production systems in all their operational modes. The use of memory-safe languages or other security tools does not guarantee that deployed systems are secure. It is important to ensure system integrity at all runtime stages and for all components to guarantee downstream security properties of languages and their compilers.
