6 Infotainment Bugs Allow Mazdas to Be Hacked With USBs

Source: Marin Tomas via Alamy Stock Photo

Six unpatched vulnerabilities in a Mazda in-vehicle infotainment (IVI) system could be exploited with a simple USB in a moments’ time, and one of them has legitimate consequences to vehicle safety.

These days, cars are just computers on wheels, and IVIs are their user interface. The IVI in most Mazda vehicles of recent years — like the Mazda3 and CX-3, 5, and 9 — are built with the Mazda Connect Connectivity Master Unit (CMU), developed by the Michigan-based Visteon Corporation. The CMU is a core hardware component that enables various connectivity services: smartphone integration, a Wi-Fi hotspot, and various remote monitoring and control features.

Recent research through Trend Micro’s Zero Day Initiative (ZDI) has surfaced half a dozen vulnerabilities in the Mazda IVI. A few of them enable full system compromise, and access to various sensitive data. One of particular note could enable an attacker to pivot to the vehicle’s Controller Area Network (CAN) bus — the central nervous system connecting its various component parts.

None of the vulnerabilities have been assigned a value according to the Common Vulnerability Scoring System (CVSS) yet. All of them remain unpatched as of this writing. On the plus side: They all require that an attacker physically insert a malicious USB into the center console. Such a scenario — carried out by a carjacker, or possibly a valet or dealer — is essentially unheard of in the real world to date.

Dark Reading has reached out to Visteon for further comment on this story.

6 Mazda IVI Security Bugs

Three of the vulnerabilities — CVE-2024-8358, CVE-2024-8359, and CVE-2024-8360 — target functions used to locate and extract specific files during software updates. Because the provided file path is not sanitized, an attacker can step in with their own malicious injection, which gets executed at the root level of the system. With a specially crafted command, this one-step hack could facilitate a full system takeover.

Another way to skin this cat would be to take advantage of CVE-2024-8357, affecting the CMU’s System on Chip (SoC) running Linux. The SoC’s boot process has no authentication in place, so an attacker with the ability to execute code can take advantage to manipulate files, establish persistence through reboots, and establish control over the system even before it boots up.

The Mazda IVI; Source: Trend Micro’s ZDI

CVE-2024-8355 might seem at first a bit different from the rest but, in reality, it’s caused by the same underlying problem: lack of sanitization of input data.

To establish a connection with an Apple device, the CMU will request the device’s serial number. Because it doesn’t apply scrutiny to that value, a spoofed device can send specially crafted SQL code instead. The system’s DeviceManager will run that code at the root level, enabling all kinds of malicious outcomes: database exposure, arbitrary file creation, etc.

Last, but certainly not least, is CVE-2024-8356, a missing verification during the CMU software update process. This one, however, affects the unit’s other processor, the Verification IP Microcontroller Unit (VIP MCU). The VIP MCU is designed to be separate from the SoC for security purposes, because instead of running the operating system, it connects to the vehicle’s CAN bus. The CAN bus, in turn, connects the rest of the vehicle: everything from climate control to the engine and airbags. With a tampered firmware image, ZDI demonstrated that one can jump the SoC to manipulate the VIP MCU, and from there reach the CAN bus.

Serious, But Unlikely Consequences

“In truth, it’s hard to predict what an attacker could do once they have access to a CAN bus,” says Dustin Childs, head of threat awareness at ZDI. “Since the CAN bus serves as the nervous system of the vehicle, a threat actor could potentially impact whatever electronic control units (ECUs) or components that interact with the CAN bus.” Translation: Attackers can subvert just about any conceivable part of the vehicle.

“The worst case scenario would be an attacker impacting the driving characteristic of the car, rendering it unsafe to operate,” he adds.

Still, the threat is immaterial. For all of the exploits demonstrated by researchers, actual criminals still consistently stick to those older tried-and-true methods of compromise: a stolen set of keys; an unfurled clothes hanger slipped artfully in between a window and a door frame; or a rock, a window, and a good baseball toss.

“At this point, there isn’t a lot of real-world impact,” Childs admits. “However, as cars become more connected, remote exploitation becomes more realistic. In the last Pwn2Own Automotive, the team from Synacktiv exploited the modem of the Tesla Model 3 over-the-air to reach and interact with the onboard systems of the vehicle. It’s just a matter of time until a complete, remote vehicle takeover becomes a real possibility.”

He adds, “That’s why manufacturers should build in security to each component and not rely on the defenses of other modules. A vehicle should have a multilayered protective system that assumes every message may be from a compromised source. The more we get ahead of the problem now, the easier it will be to react to it in the future.”

About the Author

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes “Malicious Life” – an award-winning Top 20 tech podcast on Apple and Spotify – and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts “The Industrial Security Podcast,” the most popular show in its field.