finding another fbmem.c type exploit for the S5 (aka motochopper)

Status
Not open for further replies.
Search This thread

bingo99

Member
Jun 7, 2014
8
1
for those who dont know, a bug in fbmem.c is how motochopper works.

basically it was able to allocate all the memory on the device to itself (a lowly normal user), including kernel memory.

and once that occured, it could simply change itself to be root or the usual things you can do once you have kernel memory control.

a fascinating technical description of this can by found by googling:

"android hackers handbook" and going to the google books result for that book. it starts at page 357.

my question is this:

its not like this is the very first time a memory allocation bug like this has been used to compromise a kernel and gain root in the history of linux (or the history of kernels for that matter)

I would think it would be possible to automatically search the kernel source for all locations which allocate memory and then inspect those locations manually for weaknesses.

So has someone done a systematic check like this?

Could we attempt it like this:

1) using standard source code tools, make a list of all the locations in the kernel source that allow user land code to allocate memory. (like fbmem.c) this should be done at the CODE level, i.e. if there is something that sets the size of an array or variable or pointer which resides in kernel space then that counts as a hit. I'm not talking about high level "kernel.c accesses kernel memory" I mean down to the individual line of code.

2) using standard text search tools (i.e. grep), select 1 or 2 pages of text before and after the "hit". so now you have a big pile of pages which all have the hit and the code around them.

3) create a simple way of distributing these pages to the "mailing list" of people out there for review. maybe people can be trained to recognize simple things like memory pointers being set with integers in a way that can rollover.

4) cross your fingers that someone out there has the "golden ticket" of both an actual weakness in their pages and the ability to see that weakness.

I know its a long shot that there enough people out there that know what they are looking at to find an exploit even if handed the relevant code.

But then the question still remains:

6) Has a systematic search of all userland kernel memory allocating code been attempted, and if not, is it possible to attempt somehow, and how?

7) RAY OF HOPE: remember that the fbmem.c bug that motochopper uses had been around for YEARS (If I am reading the timeline correctly) so its not like its out of the question another similar bug could exist. It went undetected by all the usual billion dollar companies and government agencies, not to mention all the other people involved in linux kernel development. Or if it is out of the question Id really like to hear why!
 
Last edited:
  • Like
Reactions: Shaffer678

bingo99

Member
Jun 7, 2014
8
1
okay so I guess what I am suggesting is just distributed source auditing, which may or may not have any merit and/or even be realistically possible with non programmers or inexperienced programmers...or even advanced programmers

but heres another way to look at it:

lets say there IS another memory leak similar to the fbmem.c weakness. just for arguments sake.

its somewhere in the kernel source code.

in fact, to make the point, lets say its EXACTLY the same kind of leak as the fbmem.c leak.

what sort of method would we need to locate it?

if we can come up with a method that would locate the fbmem.c weakness, then it would probably find other weaknesses too.

im not talking about a text find to locate the exact source code. I mean something a little more fuzzy than that..something which finds memory being allocated and there is chain going back to userland and we can find the weak link in that chain and allocate critical kernel memory.
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    for those who dont know, a bug in fbmem.c is how motochopper works.

    basically it was able to allocate all the memory on the device to itself (a lowly normal user), including kernel memory.

    and once that occured, it could simply change itself to be root or the usual things you can do once you have kernel memory control.

    a fascinating technical description of this can by found by googling:

    "android hackers handbook" and going to the google books result for that book. it starts at page 357.

    my question is this:

    its not like this is the very first time a memory allocation bug like this has been used to compromise a kernel and gain root in the history of linux (or the history of kernels for that matter)

    I would think it would be possible to automatically search the kernel source for all locations which allocate memory and then inspect those locations manually for weaknesses.

    So has someone done a systematic check like this?

    Could we attempt it like this:

    1) using standard source code tools, make a list of all the locations in the kernel source that allow user land code to allocate memory. (like fbmem.c) this should be done at the CODE level, i.e. if there is something that sets the size of an array or variable or pointer which resides in kernel space then that counts as a hit. I'm not talking about high level "kernel.c accesses kernel memory" I mean down to the individual line of code.

    2) using standard text search tools (i.e. grep), select 1 or 2 pages of text before and after the "hit". so now you have a big pile of pages which all have the hit and the code around them.

    3) create a simple way of distributing these pages to the "mailing list" of people out there for review. maybe people can be trained to recognize simple things like memory pointers being set with integers in a way that can rollover.

    4) cross your fingers that someone out there has the "golden ticket" of both an actual weakness in their pages and the ability to see that weakness.

    I know its a long shot that there enough people out there that know what they are looking at to find an exploit even if handed the relevant code.

    But then the question still remains:

    6) Has a systematic search of all userland kernel memory allocating code been attempted, and if not, is it possible to attempt somehow, and how?

    7) RAY OF HOPE: remember that the fbmem.c bug that motochopper uses had been around for YEARS (If I am reading the timeline correctly) so its not like its out of the question another similar bug could exist. It went undetected by all the usual billion dollar companies and government agencies, not to mention all the other people involved in linux kernel development. Or if it is out of the question Id really like to hear why!
    1
    Ideas for rooting the device should go in the thread entitled "Ideas for rooting our phones." Thread closed.