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!
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: