One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 8587336 |
| Date de publication | 2024-09-24 12:00:16 (vue: 2024-09-28 14:16:59) |
| Titre | Google & ARM - Raisser la barre sur la sécurité du GPU Google & Arm - Raising The Bar on GPU Security |
| Texte | Posted by Xuan Xing, Eugene Rodionov, Jon Bottarini, Adam Bacchus - Android Red Team;
Amit Chaudhary, Lyndon Fawcett, Joseph Artgole - Arm Product Security Team
Who cares about GPUs?
You, me, and the entire ecosystem! GPUs (graphics processing units) are critical in delivering rich visual experiences on mobile devices. However, the GPU software and firmware stack has become a way for attackers to gain permissions and entitlements (privilege escalation) to Android-based devices. There are plenty of issues in this category that can affect all major GPU brands, for example, CVE-2023-4295, CVE-2023-21106, CVE-2021-0884, and more. Most exploitable GPU vulnerabilities are in the implementation of the GPU kernel mode modules. These modules are pieces of code that load/unload during runtime, extending functionality without the need to reboot the device.
Proactive testing is good hygiene as it can lead to the detection and resolution of new vulnerabilities before they\'re exploited. It\'s also one of the most complex investigations to do as you don\'t necessarily know where the vulnerability will appear (that\'s the point!). By combining the expertise of Google\'s engineers with IP owners and OEMs, we can ensure the Android ecosystem retains a strong measure of integrity.
Why investigate GPUs?
When researching vulnerabilities, GPUs are a popular target due to:
Functionality vs. Security Tradeoffs
Nobody wants a slow, unresponsive device; any hits to GPU performance could result in a noticeably degraded user experience. As such, the GPU software stack in Android relies on an in-process HAL model where the API & user space drivers communicating with the GPU kernel mode module are running directly within the context of apps, thus avoiding IPC (interprocess communication). This opens the door for potentially untrusted code from a third party app being able to directly access the interface exposed by the GPU kernel module. If there are any vulnerabilities in the module, the third party app has an avenue to exploit them. As a result, a potentially untrusted code running in the context of the third party application is able to directly access the interface exposed by the GPU kernel module and exploit potential vulnerabilities in the kernel module.
Variety & Memory Safety
Additionally, the implementation of GPU subsystems (and kernel modules specifically) from major OEMs are increasingly complex. Kernel modules for most GPUs are typically written in memory unsafe languages such as C, which are susceptible to memory corruption vulnerabilities like buffer overflow.
Can someone do something about this?
Great news, we already have! Who\'s we? The Android Red Team and Arm! We\'ve worked together to run an engagement on the Mali GPU (more on that below), but first, a brief introduction:
Android Red Team
The Android Red Team performs time-bound security assessment engagements on all aspects of the Android open source cod |
| Notes | ★★ |
| Envoyé | Oui |
| Condensat | 0153 0884 2021 2023 2024 21106 3rd 4295 48409 48421 able about accelerate access accessible across actively actual adam added additionally adversaries affect affected all allowed along alongside already also altogether always amit analyses analysis analyze android another any api app appear applicable application approach apps are area arm artgole aslr aspects assess assessment assessments assurance attack attackers automate automates automatically avenue avoiding bacchus back bar based because become been before being below best better between block both bottarini bound bounds bounty brands brief broadest buffer bug building builds built bulletin but can capabilities capability carefully cares cases category caused causing central certain challenges challenging changes: chaudhary check checking checks chosen circled closely cloud code codebase collaborated collaborates collaborating collaboration collaborative collective combination combining commonly communicating communication communities company complementing complex complexity component components compromising conditions conduct conducts constraints content context continue control copies copy corruption could critical crucial customization customizations cve dedicated deep deeper degraded delivering descriptions designed destination detailed detection development device device; devices did directly directly/indirectly discover discovery dive don door driver drivers drives drove due during easier ecosystem ecosystem: effort efforts eliminate embedded enable enablement engagement engagements engineering engineers enhancements ensure entire entitlements equipment escalation etc eugene evaluate eventually example excellence excellent executed execution exist existing expand experience experiences expertise experts exploit exploitable exploitation exploited exposed extending fawcett firmware first fixed fixes fixing flow focused focusing following formal forward found frequently from function functionality fundamental further fuzzing gain general good google gpu gpus graphics great had hal handle handles handling happens hardening hardware has have heap help highlights hits how however huge hygiene identified identify impact implementation implemented important improvement improvements improving incident includes increasingly industry information initiatives inside instance instructions integer integrity interface intermediary internal interprocess introduce introduction: invested investigate investigations investment involved ioctl ipc issue issues its job jon joseph july kbase kernel kernel” key know known languages latest lead leading led leveling leverage lifecycle like limited liveness load/unload long looking looks lyndon made major make mali manipulated manual manufacturer manufacturers many match measure measures memory methods microcontrollers might millions missing mitigations mobile mode model modifications modify module modules monitoring more most multi necessarily necessary need never new news next nine nobody not noticeably objective obtain occurred oems often one open opens operates operation original other out outside overflow overwrite owners page part partner partners party patch patches path perform performance performs permissions phone physical pieces pixel please plenty point policy popular possible posted potential potentially practice practices present prevent primary privilege proactive proactively problems process processing product products productsecurity program pronged proprietary protect protection provided providers provides quickly raise raising rapid reach reboot recent red reduce reference register regular regularly relationship released relevant relies remediate remediation replicating repositories requirements requires research researching resolution resource resources respond response result retains review reviews rich risk risks rodionov run running runs runtime safety sanitizers scalability scales sdl secure security segment set sets sharing significant size slow software software/firmware sole some someone something sometimes |
| Tags | Vulnerability Threat Mobile Cloud |
| Stories | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.