Driving forward in Android drivers

https://googleprojectzero.blogspot.com/2024/06/driving-forward-in-android-drivers.html

by idiocrat • 2 years ago

103 8 2 years ago

googleprojectzero.blogspot.com

salesynerd• 2 years ago

I'm not a security professional but I have been reading about Google Project Zero's research for quite some time and I have massive respect for the team as well as Google for the work they do.

JosephRedfern• 2 years ago

I remember some crazy insecure drivers on Android drivers back in the day (2012-13 or so) -- stuff like `/dev/fbN` and `/dev/input/eventN` being world read/writeable, allowing unprivileged screen and input capture from any application.

It was far more basic than what's described in this blog post, but really good fun to poke around at.

neogodless• 2 years ago

Posted less than 24 hours ago (but likely not front page / no comments)

https://news.ycombinator.com/item?id=40673155

mschuster91• 2 years ago

However, based on open-source codebases for these different devices' kernels, it appears MediaTek is actively maintaining several different trees for this driver, likely based on the associated kernel version, and these two devices use separate trees.

This one sentence just perfectly sums up everything that's broken in the embedded (i.e. everything non-x86) world. Everyone just forks random stuff at random points in the BSP's life time, and no one makes even the slightest effort to upstream it to mainline Linux (if that's possible at all given that Android's Linux fork itself does a lot of things differently than Linux upstream likes).

I found two vulnerabilities in this driver. CVE-2023-32837 was a textbook OOB read/write in an array of structs. Various different members of the struct were accessed and modified, creating several different possibilities for exploitation, but also making them significantly more challenging. Interestingly, MediaTek partially fixed this bug in July 2021, although the exact date this patch went out to OEMs is unclear.

And that's the second point of danger. All the forks floating around make distributing patches in an efficient way all but impossible.

The fact that it's Google complaining here makes it all the more hilarious IMHO. Google are the ones who could fix this in an instant: demand upstreaming (or at least, reasonable efforts towards that) as a part of getting the Play Store certification.

A side note towards root exploit hunters: MediaTek's stuff is particularly gory. I'll admit my knowledge is some years dated, but I can't imagine that their code style and code quality has improved over the time...

PlutoIsAPlanet2• 2 years ago

This one sentence just perfectly sums up everything that's broken in the embedded (i.e. everything non-x86) world. Everyone just forks random stuff at random points in the BSP's life time

A few years ago I did some work that involved building a custom Android image for a SoC manufacturer that's common in TVs.

The BSPs were provided over FTP as split up archive files, held together by bash scripts and had 100s of .patch files scattered all over the place. I am not sure if still the case, but there was also GPL-affected code (kernel patches/modules) that the were certainly not being open sourced at the time.

For each Android point update there was a new set of archives and painful rebasing of the changes we had made on top.

I know there have been changes since, with GSIs etc, but these to me just seem like band aids on the problem.

yjftsjthsd-h2• 2 years ago

Shortening this propagation delay (e.g. using Android APEX to ship updated kernel drivers) would go a long way to minimizing the Android driver patch gap.

Oh, I didn't realize APEX could ship kernel modules; that's neat.

PlutoIsAPlanet2• 2 years ago

Curious how that works given the kernel has no stable kernel<>kernel ABI.

yjftsjthsd-h2• 2 years ago

I wondered the same, but I'm assuming it's just a faster way for the vendor to ship an updated .ko to a known kernel. That is, for existing phone myphone3a-variant7 there is an existing kernel 5.10.123-myphone3a-variant7 and the vendor wants to fix a bug in it; they can either ship a whole OS update containing 5.10.124-myphone3a-variant7 or they can build 5.10.124-myphone3a-variant7, pull out the one .ko that actually changed, stick that in an APEX update, and ship that, thereby getting the update out much faster and with less (no?) action on the part of users.

At least, that's what I'm guessing; I can't tell for sure either:P

Driving forward in Android drivers

Related Stories