Beyond the zero-click vulnerability we discussed in a previous blog entry, additional vulnerabilities were discovered in the Alpine Halo9 iLX-F509 in-vehicle infotainment (IVI) system during Pwn2Own Automotive 2024. Alex Plaskett and McCaulay Hudson, researchers from the NCC Group’s Exploit Development Group, demonstrated exploits leveraging two vulnerabilities: CVE-2024-23961 (command injection) and CVE-2024-23960 (improper verification of cryptographic signature). By combining these, they created a two-bug chain that enabled them to run the classic first-person shooter game Doom on the Alpine device.
The researchers shared their findings and exploitation techniques during a presentation at the RomHack 2024 conference. This blog entry highlights the key takeaways from their presentation and outlines countermeasures to address the issues.
Figure 1. The NCC Group executed a two-bug chain against the Alpine Halo9 iLX-F509 IVI system and then played Doom on the device.
Image from the Zero Day Initiative (ZDI)
The Zero Day Initiative (ZDI), VicOne’s co-host for Pwn2Own Automotive and partner in vulnerability discovery and disclosure, reported both vulnerabilities to Alpine. After conducting a threat assessment and remediation analysis (TARA) in line with ISO/SAE 21434, the vendor classified the vulnerability as “sharing the risk.” This designation reflects a decision to accept the residual risk and continue using the current software without issuing a patch.
Hardware analysis and firmware dump
The researchers began their investigation by dismantling the Alpine Halo9 iLX-F509 hardware to examine its components. They confirmed the presence of an eMMC chip, a nonvolatile memory device, using a logic analyzer. With the aid of an SD sniffer, they successfully extracted a dump of the eMMC’s contents, which, surprisingly, was stored in plaintext. The absence of encryption significantly streamlined their reverse engineering efforts, enabling deeper exploration of the firmware.
Command injection vulnerability
The command injection vulnerability, CVE-2024-23961, requires a complex trigger process. It is introduced during the over-the-air (OTA) firmware update, where only the OTA firmware is encrypted.
During the update, the system retrieves two files: a zip file (RLDEFAULT_A.23.D0.05.00.01.00) and an associated file, collective_sign_info.dat (RLDEFAULT_A.23.D0.05.00.01.00_2). Both files are partially encrypted. The collective_sign_info.dat file consists of four main sections:
- Header
- upd_pkg.sig – an RSA SHA-256 signature
- host_info.dat – partially encrypted using AES128
- pkg_info.sig – another RSA SHA-256 signature
In host_info.dat, the encrypted portion uses AES128 with an initialization vector (IV) of 0000000000000000. Notably, this IV is stored in plaintext within the same file. Two hardcoded AES keys in updatemgr allow decryption of host_info.dat, revealing the password 0123456789. This password is subsequently used to extract the contents of the zip file, RLDEFAULT_A.23.D0.05.00.01.00. (One notable issue is that the hardcoded AES keys in updatemgr are easily extractable for decrypting files. Another is that the weak zip password, 0123456789, is highly susceptible to brute-force attacks.)
During the firmware update process, the function UPDM_wemCmdUpdFSpeDecomp in updatemgr calls the 7za utility to decrypt the zip file. However, it does not adequately validate the parameters passed to 7za. This oversight enables command injection, allowing attackers to execute arbitrary commands by manipulating the parameters.
Improper verification of cryptographic signature vulnerability
CVE-2024-23960 highlights a significant flaw that lies in the signature verification process. While the system is designed to validate the RSA SHA-256 signature files before proceeding with the update, a backdoor mechanism, likely left for debugging purposes, enables bypassing this verification entirely.
If the UPDM_wbIsForceUpdFileExist function detects a specific ForceUpdFile file, it bypasses the package information signature check. The path to this bypass file is hardcoded and encrypted within the program, thus decrypting ForceUpdate.bin. Attackers can bypass the cryptographic signature check by simply placing ForceUpdate.bin in the root directory of a USB drive.
Conclusion
Command injection is a common issue in embedded Linux devices, highlighting the need for stringent parameter validation to prevent unauthorized command execution. In this case, the researchers creatively demonstrated their exploit by running Doom on the device, underscoring the range of possibilities — and the far more serious threats — that attackers can execute once they gain root access.
To mitigate the risks, automotive manufacturers (OEMs) should adopt a comprehensive approach to security testing. This includes static, interactive, and dynamic application security testing (SAST, IAST, and DAST), along with regular penetration testing, to uncover and address vulnerabilities proactively.
Moreover, if firmware flash images can be easily dumped, not only does the risk of intellectual property theft increase, but the device is also exposed to potential vulnerabilities. OEMs should therefore consider integrating hardware security modules (HSMs) or secure elements (SEs) to safeguard critical data.
Finally, before releasing production versions of the code, developers must conduct a thorough review to remove any debugging backdoors or tools used during development. This step is crucial to preventing potential exploitation once the device is already deployed in the field.
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.
