Who gives a hoot about GPUs?
We all do! GPUs (graphics processing units) play a vital role in providing immersive visual experiences on smartphones. Nevertheless, the GPU software and firmware stack has emerged as a vulnerable spot for attackers seeking permissions and entitlements (privilege escalation) on Android-based devices. The realm of GPU vulnerabilities extends across leading GPU brands, showcasing issues like CVE-2023-4295, CVE-2023-21106, CVE-2021-0884, and more. Most exploitable vulnerabilities in GPUs stem from the implementation of GPU kernel mode modules. These modules are code snippets that can be loaded/unloaded dynamically, expanding functionality without requiring a device reboot.
Proactive testing serves as a crucial practice as it facilitates the early identification and resolution of fresh vulnerabilities before they are exploited. This investigative process is intricate as the vulnerability’s location may be uncertain (and that’s the challenge!). By leveraging the collective know-how of Google’s engineers alongside IP holders and OEMs, we can uphold the integrity of the Android ecosystem.
Why delve into GPUs?
In the realm of vulnerability exploration, GPUs hold a prominent position due to:
- Balancing Functionality and Security
Nobody desires a sluggish, unresponsive device; any hindrance to GPU performance could severely impact user experience. Consequently, the Android GPU software stack relies on an in-process HAL model where the API & user space drivers interact directly with the GPU kernel mode module within application contexts, bypassing interprocess communication. This setup creates a potential scenario where untrusted code from third-party apps could directly tap into the GPU kernel module’s exposed interface. If any vulnerabilities exist in the module, third-party apps can exploit them. This scenario allows potentially untrusted code running within a third-party app context to directly access the GPU kernel module’s interface and exploit any kernel module vulnerabilities.
- Diversity & Memory Protection
Furthermore, the construction of GPU subsystems (specially kernel modules) from major OEMs has grown increasingly intricate. Kernel modules for numerous GPUs are predominantly coded in memory-vulnerable languages like C, making them susceptible to memory-related flaws such as buffer overflow.
Is there a solution to this?
Absolutely! The Android Red Team and Arm have collaborated on this front! Who are these collaborators? It’s the Android Red Team and Arm! They combined efforts to conduct a comprehensive assessment on the Mali GPU (more details below), but first, an overview:
Android Red Team
The Android Red Team executes time-limited security evaluation assignments covering all facets of the Android open-source codebase. They also conduct regular security checks on internal Android components. Throughout these missions, the Android Red Team teams up with third-party software and hardware providers to explore proprietary and “closed source” code repositories, aiming to pinpoint security threats and potential vulnerabilities before malevolent entities exploit them. This year, the Android Red Team collaborated directly with Arm, our industry partner, to carry out the Mali GPU assessment and fortify security on numerous Android devices.
Arm Product Security and GPU Teams
Arm houses a central product security unit that sets governance and methodology across the organization. They possess product security specialists integrated within engineering teams. Arm follows a structured approach to prevent, identify, and eradicate security vulnerabilities, which includes a Security Development Lifecycle (SDL), a Monitoring feature, and Incident Response. For this partnership, the Android Red Teams received assistance from security experts embedded within Arm’s GPU engineering team.
Collaborative Efforts for Securing Android Devices
Google’s Android Security divisions and Arm have been collaborating extensively. Security prerequisites are always evolving, and challenges persist with all GPU providers. By consistently sharing insights, the Android Red Team and Arm expedited the detection and resolution process. Assessments of identified vulnerabilities, prospective remedial tactics, and fortifying measures led to meticulous analysis and implementation of patches where necessary.
Recent examinations have primarily centered around the Mali GPU due to its pervasive usage in contemporary Android devices. Joint efforts on GPU security facilitated:
- Surveying the Impact across the Widest Spectrum of the Android Ecosystem: The Arm Mali GPU stands out as one of the most adopted GPUs by original equipment manufacturers (OEMs) and features in numerous popular mobile devices. By concentrating on the Arm Mali GPU, the Android Red Team could evaluate the security of a GPU implementation running on countless Android devices globally.
- Reviewing the Core Implementation and Manufacturer-Specific Modifications: Device manufacturers often tweak the upstream GPU implementation to tailor it to their particular devices. These alterations and enhancements pose challenges and may introduce security vulnerabilities not present in the original GPU version. In this specific scenario, the Google Pixel team collaborated actively with the Android Red Team to comprehend and secure the modifications implemented for Pixel devices.
Enhancements
The investigations have yielded substantial enhancements, uplifting the security of the GPU software/firmware stack across a significant portion of the Android ecosystem.
Assessing the Kernel Driver
An integral element of the GPU subsystem is its kernel mode driver. Throughout this assessment, both the Android Red Team and Arm invested substantial efforts in scrutinizing the Mali kbase kernel driver. Given its intricacy, fuzzing emerged as the primary testing methodology for this segment. Fuzzing automates and amplifies vulnerability detection in ways unimaginable through manual means. With support from Arm, the Android Red Team augmented the syzkaller fuzzing descriptions to align with the latest Mali kbase driver architecture.
The team devised several adaptations to enable fuzzing on the Mali kbase driver in the cloud, eliminating the need for physical hardware.This led to a significant enhancement in fuzzing performance and expandability. Thanks to the assistance from the Pixel team, we were also successful in initiating fuzzing on physical Pixel devices. By utilizing a combination of cloud-driven fuzzing, Pixel-oriented fuzzing, and manual inspection, we were able to reveal two memory-related issues in Pixel’s customization of driver code (CVE-2023-48409 and CVE-2023-48421).
The identified issues manifested within the gpu_pixel_handle_buffer_liveness_update_ioctl function, which forms part of the device-specific customization carried out by the Pixel team. Both issues stemmed from memory problems arising due to integer overflow issues. If tactfully exploited along with other vulnerabilities, these issues could potentially lead to a user-space to kernel privilege escalation. Both problems were promptly addressed, and the necessary patch was rolled out to affected devices in the form of the Pixel security bulletin dated 2023-12-01.
Assessing Firmware
On another note, firmware plays a crucial role in the GPU subsystem as an essential component. It serves as an intermediary that interacts with kernel drivers and GPU hardware. In numerous scenarios, the functionality of firmware can be directly or indirectly accessed from applications. Hence, the attack flow “application ⇒ kernel ⇒ firmware ⇒ kernel” is a recognized pathway within this domain. Moreover, firmware typically operates on embedded microcontrollers with limited resources. The application of commonly utilized security kernel mitigations (such as ASLR, stack protection, heap protection, specific sanitizers, etc.) may not be feasible for firmware due to constraints in resources and performance implications. This situation can sometimes render compromising firmware easier compared to directly targeting kernel drivers from user space. To validate the integrity of existing firmware, the Android Red Team and Arm collaborated to conduct fuzzing, formal verification, and manual scrutiny. This multifaceted approach led to the identification of CVE-2024-0153, for which a patch was released in the July 2024 Android Security Bulletin.
CVE-2024-0153 occurs when the GPU firmware processes specific instructions. During the handling of such instructions, the firmware copies the contents of registers into a buffer. Although there are size checks before the copy operation, under extremely precise conditions, an out-of-bounds write incident may take place on the target buffer, resulting in a buffer overflow. When meticulously manipulated, this overflow can overwrite crucial structures situated beyond the buffer, leading to code execution within the GPU firmware.
The prerequisites for encountering and potentially exploiting this issue are intricate, demanding a profound understanding of instruction execution mechanisms. Leveraging a collective pool of expertise, the Android Red Team and Arm confirmed the exploitation path and exploited the issue to attain restricted control over GPU firmware. Subsequently, this control was leveraged to circle back to the kernel, allowing for privilege escalation. Arm took swift action in responding to and resolving the issue effectively. This entire episode underscores the importance of collaboration between the two teams in delving into complex matters.
Patching Timelines
It is a known fact that malicious actors exploit GPU vulnerabilities in live environments, underscoring the criticality of rapid patching to mitigate the risk of potential exploitation and safeguard the end users. Following this engagement, nine new tests were integrated into the Security Test Suite (STS) to aid partners in automatically verifying their builds for missing Mali kbase patches. The Security Test Suite is a software tool offered by Google to assist partners in automating the process of validating their builds for any absent security patches.
Future Prospects
The Arm Product Security Team actively participates in security-oriented industry forums and maintains close collaborations with ecosystem partners. For instance, the partnership with the Android Red Team serves as a valuable avenue for enabling best practices and product superiority. Building upon this collaborative ethos, Arm is enhancing its product security assurance capabilities by introducing a bug bounty program. This initiative is set to broaden Arm’s endeavors in identifying potential vulnerabilities. To delve deeper into Arm’s product security initiatives, you can explore the content available on their product security page.
The Android Red Team and Arm persist in their joint efforts to proactively elevate GPU security standards. Through meticulous testing, prompt remediation, and updates to the security test suite, we are collectively advancing the ecosystem for Android users. The Android Red Team is keen on replicating this collaborative model with other ecosystem partners to fortify the security posture of devices.
About Author
