Driving forward in Android drivers

  • > 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...

  • 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.

  • 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.

  • > 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.

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

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