By Vit Sembera (Senior Threat Researcher, Automotive)
The Pwn2Own Automotive 2024 competition revealed multiple vulnerabilities in the Alpine Halo9 iLX-F509 in-vehicle infotainment (IVI) system. Among them was CVE-2024-23923, a zero-click use-after-free (UAF) remote code execution (RCE) vulnerability in the proprietary Bluetooth stack. Discovered by Mikhail Evdokimov, a senior security researcher from PCAutomotive, this vulnerability highlights critical security concerns in modern automotive systems, where proprietary solutions often lack essential safeguards.
The Zero Day Initiative (ZDI), VicOne’s co-host for Pwn2Own Automotive and partner in vulnerability discovery and disclosure, has since reported CVE-2024-23923 to Alpine. After conducting a threat assessment and remediation analysis (TARA) under ISO/SAE 21434, the vendor classified the vulnerability as “sharing the risk,” indicating a decision to accept the residual risk, and chose to continue using the current software without releasing a patch.
Firmware extraction and initial discovery
The vulnerability analysis began with extracting the firmware directly from the device’s eMMC chip, without desoldering the component. The vendor’s decision to leave debug symbols intact in the production firmware simplified the task of reverse-engineering the code. This ease of access allowed for a thorough examination of the system’s Bluetooth stack, ultimately leading to the discovery of the critical flaw.
For a detailed walkthrough of the vulnerability analysis, refer to the researcher’s Hexacon 2024 presentation, “0-click RCE on the IVI component: Pwn2Own Automotive edition.”
UAF in Bluetooth ACL handling
CVE-2024-23923 was discovered in the code of the Bluetooth Host Controller Interface Asynchronous Connection-Oriented Logical Link (HCI ACL), a data transport mechanism within the Bluetooth protocol stack. Through static analysis, the researcher uncovered the use-after-free (UAF) vulnerability in the code.
This vulnerability could be triggered under specific conditions involving three sequential incoming asynchronous connection-less protocol data units (ACL PDUs). Notably, the vulnerability is particularly severe as it can be exploited prior to Bluetooth authentication, significantly expanding the attack surface to include attack scenarios that require no user interaction.
Several factors contributed to the ease of exploitation: The process ran with root privileges, used fixed addresses, and lacked critical security mitigations such as stack canaries and address space layout randomization (ASLR). These omissions created an environment highly conducive for effective exploitation by attackers.
From 60% to 96% exploitation success rate
The researcher’s initial exploitation attempts achieved a 60% success rate, which he refined to an impressive 96% through meticulous adjustments. His strategy involved developing several exploitation “primitives” to manipulate the system’s memory with precision. Below is an overview of the techniques he employed:
- Universal heap spraying: Controlled the heap memory layout to increase the likelihood of successful exploitation.
- Arbitrary address write (AAW): Leveraged enhanced retransmission mode (ERTM) channel I-frames to perform arbitrary heap writes. Although these channels typically become available only after Bluetooth authentication, he bypassed this limitation by exploiting a heap overflow condition. He needed to solve an issue of selecting a proper heap arena which he solved by checking heap chunk flags.
- Heap segment memory leak: Used Logical Link Control and Adaptation Protocol (L2CAP) echo request/response packets to leak heap segment addresses. By modifying response lengths and applying the AAW primitive, he was able to observe the memory structure.
- Arbitrary address read (AAR): Exploited ERTM channel S-frame reject protocol data units (REJ PDUs) to modify heap pointers, enabling the reading of arbitrary memory locations.
- libc address and system function discovery: Traversing the malloc_state structure in heap memory using the AAR primitive to locate key libc addresses, including the system() function required for remote code execution.
- Bluetooth thread stack address extraction: Retrieved the Bluetooth thread stack address via the corresponding thread control block (TCB) in libpthread. Using the AAR primitive, he navigated the double-linked list where TCBs resided.
- Return-oriented programming (ROP) chain creation: Constructed an ROP chain on the stack, enabling system-level command execution.
Through these carefully orchestrated steps, the researcher achieved zero-click remote code execution (RCE) with high stability.
Security takeaways from the Bluetooth attack vector
This UAF vulnerability in the Alpine Halo9 IVI system highlights the risks associated with proprietary implementations of widely used technologies like Bluetooth. In this case, the vulnerability was located in the basic L2CAP layer, just above the HCI, rather than in the stack’s higher, more specialized layers. The vendor’s decision to use a proprietary Bluetooth stack, instead of a well-tested, industry-standard solution, significantly increased the system’s exposure to security risks.
Compounding the issue, the absence of essential security mitigations — such as stack canaries, ASLR, and stripped debug symbols in production firmware — left the system highly susceptible to exploitation. Bluetooth, with its inherent complexity, remains a preferred attack vector, as frequent implementation errors make it a fertile ground for vulnerabilities, as this case demonstrates.
The discovery of CVE-2024-23923 underscores the importance of adopting secure, industry-verified protocols and implementing robust cybersecurity measures. Proprietary solutions often introduce avoidable risks, and as connected technologies proliferate in the automotive industry, automotive manufacturers and suppliers alike must prioritize security best practices to protect their systems and users.
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.
