There is a sticker on the bottom with some technical information about the unit. The sticker notes the specific CMU model being MAZDA_GEN_65_CMU.

On the back, the unit provides multiple connectors that carry power, audio input/output, USB and CAN signals, and a serial console.

Inside, the unit is built on a single PCB which carries an application SoC (Freescale part number SCIMX06DAVT10AC), an assortment of memory ICs (a serial Flash on the back of the board, a NAND Flash, and an eMMC), an auxiliary MCU (Renesas part number R5F35MCEJFF), and a Bluetooth module (Murata part number LBEE6Z2U0C-584).

While there is a login prompt, authentication credentials for the latest software version are not publicly known. The console proceeds to serve a vast amount of logging output, which could be useful for testing exploits.

When fully booted, the system has the following file systems mounted:

All the persistent memory storage is accessible from the OS. The serial Flash is present as the mtdblockpartitions, the NAND is present as the ffx01 partitions, and the eMMC as the mmcblk partitions. Notably, several file systems are mounted read-write as signified by the rw string included in parentheses.

The Software Update Process

The software on the unit can be updated from the diagnostic menu:

The update process expects a file with the .up extension to be located on a mass storage device connected via USB. The dealer could then enter this diagnostic menu and start the update process.

Software update files are password-protected ZIP archives containing multiple directories for various steps in the update process, as well as an “instruction” file describing how to perform the update. There are 21 steps in the latest update file. Of special interest is the contents of the following directories:

• rootfs1upd containing a .tar.gz archive of the entire root file system,
• linux1 containing the Linux kernel 3.0.35,
• ibc1 and ibc2 containing a bootloader,
• bootstrap containing yet another bootloader,
• passwdupdate containing the replacement passwd file,
• vip containing the update image for the auxiliary MCU.

The majority of the update process is implemented in several shared objects. All business logic is located in svcjciupdatea.so and svcjciupdates.so, which use supporting code in libjcireflashua.so and libjcisecurity.so. The update process was investigated only up to the point of signature verification. Further investigation would assume the ability to produce either properly signed updates or a signature verification bypass. Unfortunately, the former was not available at the time of this research, and the latter was not discovered during this effort.

On a high level, the update verification process is contained in the svcjciupdates.so:updates_sys_srv_ValidatePackageOperationThread() function, which calls other functions to perform verification steps in the given order:

• updates_sys_srv_LoadUP() parses the specified update file, extracts the main_instructions.ini and versions.ini files, and stores them in memory for later use.
• updates_sys_srv_ValidateUPStructure() validates whether the internal structure of the update file matches the expected layout. This was not an issue when the format of proper update files was followed to create an exploit.
• updates_sys_srv_ExtractCertificates() extracts the signing certificate chain from the update file to be used for update verification. The chain contains the publisher certificate used to sign the update and an intermediate CA certificate that issued the publisher certificate. The intermediate CA certificate is issued by the JCI root CA.
• updates_sys_sec_VerifyUPCertificates() verifies the extracted certificate chain to ensure the chain properly terminates in the expected root CA stored on the device.
• updates_sys_sec_VerifyUPSignature() verifies the signature of a specified update file against the publisher certificate. The signature in this case is located at the end of the update file and is 256 bytes long.
• updates_sys_srv_RemoveExtractedCertificates() cleans up after the verification process.

Of particular note is the fact that multiple operations are performed on the supplied update file by the updates_sys_srv_LoadUP() function and its callees before any integrity checks occur against the user-supplied file.

The specific vulnerability exists in the eInsertDeviceEntry() function of the /jci/devicemanager/libdevicemanager.so library. When attempting to insert a new Apple device into the DeviceDatabase.db SQLite database, several values are taken from the device and used in an SQL statement without sanitization. See the following pseudocode implementation of the eInsertDeviceEntry() function:

Because of this, when the infotainment system detects an Apple device has been connected and requests, for example, its iAP serial number, a spoofed iPod or other Apple device can instead reply with a string along the lines of:

One of the multitude of functions supporting the update process is the REFLASH_DDU_FindFile() function found in the libjcireflashua.so shared object. The pseudocode for this function is reproduced below for clarity:

The function attempts to find a specific file within the update package specified via the provided file path. This is performed by interpolating the provided path into a command line for the unzip program. Unfortunately, no sanitization is performed before that occurs, and attacker-controlled input (e.g., /dev/sda1/path/file.up) is passed to the system() function. This allows the attacker to inject arbitrary OS commands that will be executed by the head unit OS shell, allowing for a full compromise of the system. The attacker can control both the path and file elements of the overall path.

The affected function can be reached via the following call graph:

• UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc in svcjciupdates.so
• UPDATES_SYS_SRV_GetPackageInfo
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_LoadUP
• REFLASH_UA_LoadUP in libjcireflashua.so
• REFLASH_DDU_FindFile

One of the multitude of functions supporting the update process is the REFLASH_DDU_ExtractFile() function found in the libjcireflashua.so shared object. The pseudocode for this function is reproduced below for clarity:

The function attempts to extract a specific file from the update package specified by the path supplied through the up_path argument. This interpolates the provided path into a command line for the unzip program. Unfortunately, no sanitization is performed before that occurs, and attacker-controlled input (e.g., /dev/sda1/path/file.up) is passed to the system() function. The attacker can control both path and file elements of the overall path. This allows the attacker to inject arbitrary OS commands that will be executed by the head unit OS shell, allowing for a full compromise of the system.

The affected function can be reached via the following call graph:

• UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc in svcjciupdates.so
• UPDATES_SYS_SRV_GetPackageInfo
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_LoadUP
• REFLASH_UA_LoadUP in libjcireflashua.so
• REFLASH_DDU_ExtractFile

One of the various functions supporting the update process is the UPDATES_ExtractFile() function found in the svcjciupdates.so shared object. The pseudocode for this function is partially reproduced below for clarity:

The function attempts to extract a specific file from the update package specified by the path supplied through the up_path argument. This interpolates the provided path into a command line for the unzip program. As with the other bugs, no sanitization is performed before that occurs, and attacker-controlled input (e.g., /dev/sda1/path/file.up) is passed to the system() function. The attacker can control both path and file elements of the overall path. This allows the attacker to inject arbitrary OS commands that will be executed by the head unit OS shell, allowing for a full compromise of the system.

The affected function can be reached via the following call graph:

• UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc in svcjciupdates.so
• UPDATES_SYS_SRV_GetPackageInfo
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_LoadUP
• updates_sys_srv_ExtractCertificates
• updates_sys_srv_ExtractPubCert
• UPDATES_ExtractFile("publisher_cert.pem", "/tmp/reflash/publisher_cert.pem")

Here, the mtd0 partition stores the bootstrap code, which appears to be the first piece of code to be executed on the system. The application SoC was found to be missing any authentication of this bootstrap code. Additionally, none of the subsequent OS boot steps perform any authentication of the next boot stage before passing control to it. This results in the following opportunities for an attacker who has gained code execution on the Linux system:

• Manipulate the root filesystem, changing arbitrary files and e.g. gaining persistence on the system,
• Manipulate configuration data residing in the mtd5 partition, e.g. installing arbitrary SSH keys, and
• Manipulate the bootstrap code, gaining the ability to execute arbitrary code prior to OS boot.

The MCU in question is identified as VIP in the strings found in the CMU software. Through the analysis of software update packages, it was discovered the VIP is also updated during the software update process. The tools to do so, as well as the update image, are found in the vip subdirectory of the update package.

The vcm tool allows performing the following operations against the VIP:

Specifically, the --write-image command allows writing an update image to the VIP. This command is normally used by the update script and takes an input file formatted as Motorola S-records. Of particular interest is also querying the versions of VIP software components. The following is reported on the unit running software cmu150_NA_74.00.324A:

These strings can be located in the update file image-vip_appvfbl.mot and are destined to be programmed at memory address 0xC000A in the VIP MCU memory space and appear to be part of the application image spanning addresses 0xC0000 through 0xFFFFF. By modifying these strings, it is possible to determine whether the image is validated before being programmed into the internal memory.

The original S-record file was manipulated to change one string to produce a visible indication of different firmware, and the resulting image was programmed back to the VIP MCU:

Using the same command for version check, it is possible to confirm the tampered image was accepted:

Exploitation of the OS command injection vulnerabilities is relatively straightforward. All the attacker needs to do is create a file on a FAT32-formatted USB mass storage device where the name will contain the OS commands to be executed. The filename must end with .up for it to be recognized by the software update handling code. While all three command injection vulnerabilities are exploited via the file name, the easiest one to exploit is by far the ZDI-CAN-23420 as there are no specific exploitation requirements such as validity of the crafted update file.

Exploitation of the described command injection vulnerabilities can be further facilitated by the fact that software update installation can be triggered automatically upon connecting a USB mass storage device; this is a “known feature” which is activated by simply placing an empty file named jci-autoupdate on the storage device.

Once the initial compromise is achieved, the attacker can gain persistence through manipulation of the root file system, such as installing backdoored system components which will persist across system restarts.

Furthermore, the attacker can move laterally and install a specially crafted VIP microcontroller software allowing unfettered access to vehicle networks, potentially impacting vehicle operation and safety. Specific impacts (what could be controlled and how) were not investigated during this research effort.

In the lab environment, the entire attack chain – from plugging in a USB drive to installing a crafted update on the VIP – takes only a few minutes. Currently, there is no reason to believe a similar attack will take significantly more time against a unit installed in a car. This means that the vehicle can be compromised while, for example, it is being handled by a valet, during a ride share, or via USB malware. Naturally, the same can be done in a shop environment where there are no significant time pressures.

The CMU can then be compromised and “enhanced” to, for example, attempt to compromise any connected device in targeted attacks that can result in DoS, bricking, ransomware, safety compromise, etc.