One Article Review
| Source |  ProjectZero |
|---|---|
| Identifiant | 8516986 |
| Date de publication | 2024-06-13 11:03:53 (vue: 2024-06-13 18:06:53) |
| Titre | Conduire dans les pilotes Android Driving forward in Android drivers |
| Texte | Posted by Seth Jenkins, Google Project ZeroIntroduction Android\'s open-source ecosystem has led to an incredible diversity of manufacturers and vendors developing software that runs on a broad variety of hardware. This hardware requires supporting drivers, meaning that many different codebases carry the potential to compromise a significant segment of Android phones. There are recent public examples of third-party drivers containing serious vulnerabilities that are exploited on Android. While there exists a well-established body of public (and In-the-Wild) security research on Android GPU drivers, other chipset components may not be as frequently audited so this research sought to explore those drivers in greater detail.Driver Enumeration: Not as Easy as it Looks This research focused on three Android devices (chipset manufacturers in parentheses): - Google Pixel 7 (Tensor) - Xiaomi 11T (MediaTek) - Asus ROG 6D (MediaTek) In order to perform driver research on these devices I first had to find all of the kernel drivers that were accessible from an unprivileged context on each device; a task complicated by the non-uniformity of kernel drivers (and their permissions structures) across different devices even within the same chipset manufacturer. There are several different methodologies for discovering these drivers. The most straightforward technique is to search the associated filesystems looking for exposed driver device files. These files serve as the primary method by which userland can interact with the driver. Normally the “file” is open’d by a userland process, which then uses a combination of read, write, ioctl, or even mmap to interact with the driver. The driver then “translates” those interactions into manipulations of the underlying hardware device sending the output of that device back to userland as warranted. Effectively all drivers expose their interfaces through the ProcFS or DevFS filesystems, so I focused on the /proc and /dev directories while searching for viable attack surfaces. Theoretically, evaluating all the userland accessible drivers should be as simple as calling find /dev or find /proc, attempting to open every file discovered, and logging which open |
| Notes | ★★★ |
| Envoyé | Oui |
| Condensat | &dmabuf &hwid &jpeg “mediatek &bufinfo &eara &eas &fops &ibuf &index &obuf &progress &xgff &pnsparmas &taskparams hybrid timeout usleep if ret = wait sizeof timeout *pstatus = jpeg bufinfo dec do enable jpeg return sizeof /* set timeout */ //we dec disable hwid = pnsparmas if jpeg |
| Tags | Tool Vulnerability Threat Patching Mobile Technical |
| 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.