[HN Gopher] Driving forward in Android drivers
       ___________________________________________________________________
        
       Driving forward in Android drivers
        
       Author : idiocrat
       Score  : 86 points
       Date   : 2024-06-14 11:16 UTC (11 hours ago)
        
 (HTM) web link (googleprojectzero.blogspot.com)
 (TXT) w3m dump (googleprojectzero.blogspot.com)
        
       | salesynerd wrote:
       | 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 wrote:
       | 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 wrote:
       | Posted less than 24 hours ago (but likely not front page / no
       | comments)
       | 
       | https://news.ycombinator.com/item?id=40673155
        
       | mschuster91 wrote:
       | > 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...
        
       | yjftsjthsd-h wrote:
       | > 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.
        
       ___________________________________________________________________
       (page generated 2024-06-14 23:02 UTC)