5 ms·

Big horking one missing from the list: run native code. From here you can pretty much do anything, since the average handset is shipped with an ancient buggy k

Big horking one missing from the list: run native code. From here you can pretty much do anything, since the average handset is shipped with an ancient buggy kernel. The short answer remains: treat software on Play with the same distrustful contempt you would treat random no-name desktop software found in the dark corners of the Internet.

huggyface 15y ago
Can you qualify this? Native code is sandboxed just as managed code is (of course it is). Ancient buggy kernel? Most handsets have very contemporary kernels. But surely you will provide some compelling citations.
- ge0rg 15y ago
  Basically every device for which some kind of rooting tool exists is vulnerable. It is not too hard to leverage the same exploit used by rooting tools to circumvent the UID based sandbox and to access the data of other applications, including the phone book, security tokens / passwords stored in SharedPreferences etc.
  - saurik 15y ago
    However, with a buggy kernel, you don't necessarily need native code to perform the exploit: you just need access to whatever part of the kernel that has the bug (which is often something innocuous). If there is a bug in the filesystem driver where attempting to open file descriptor to paths larger than 1024 bytes long will cause a buffer overflow, I can exploit that just as easily from Java as I could from C.
  - huggyface 15y ago
    Basically every device for which some kind of rooting tool exists is vulnerable. Most if not all rooting tools work via the debug interface. One rather clever app -- if you have USB debugging turned on -- would essentially do a localhost debug connection to exploit this, but generally these are ADB exploits. This has nothing to do with native versus managed, and native provides no additional opportunity than managed. I replied to the original post because there is a pretty prolific belief that native=crazy dangerous. Yet of course the iPhone has entirely native apps, and we've had native sandboxing and rights restrictions since...what...the creation of UNIX?
- saurik 15y ago
  Well, as an example, if you are using 4.0.0-3 you probably have a kernel susceptible to mempodipper (although that's "buggy", not "ancient", and it is not possible to exploit that bug from an app: you have to do it over adb). https://github.com/saurik/mempodroid https://github.com/saurik/mempodroid Regardless, it is true: most of the exploits that have been used (Rage Against the Cage, GingerBreak, zergRush) have been in user-land components (adbd, vold, libsysutils), not in the kernel. On Android 1.x, though: kernel bugs FTW.
- stonemetal 15y ago
  http://en.wikipedia.org/wiki/Android_version_history http://en.wikipedia.org/wiki/Android_version_history http://en.wikipedia.org/wiki/Linux_kernel#Timeline http://en.wikipedia.org/wiki/Linux_kernel#Timeline From these two it is fairly easy to tell how current the kernel is for any rev of android out there. A quick cross comparison shows that it was more or less current at time of release but isn't updated afterwards. This means there are quite a few three or four year old kernels out there since most devices are in the 2.x range. I am not sure what qualifies as ancient, but I never really had a problem with the 2.6 kernel line.

huggyface 15y ago

Can you qualify this? Native code is sandboxed just as managed code is (of course it is). Ancient buggy kernel? Most handsets have very contemporary kernels. But surely you will provide some compelling citations.

ge0rg 15y ago
Basically every device for which some kind of rooting tool exists is vulnerable. It is not too hard to leverage the same exploit used by rooting tools to circumvent the UID based sandbox and to access the data of other applications, including the phone book, security tokens / passwords stored in SharedPreferences etc.
- saurik 15y ago
  However, with a buggy kernel, you don't necessarily need native code to perform the exploit: you just need access to whatever part of the kernel that has the bug (which is often something innocuous). If there is a bug in the filesystem driver where attempting to open file descriptor to paths larger than 1024 bytes long will cause a buffer overflow, I can exploit that just as easily from Java as I could from C.
- huggyface 15y ago
  Basically every device for which some kind of rooting tool exists is vulnerable. Most if not all rooting tools work via the debug interface. One rather clever app -- if you have USB debugging turned on -- would essentially do a localhost debug connection to exploit this, but generally these are ADB exploits. This has nothing to do with native versus managed, and native provides no additional opportunity than managed. I replied to the original post because there is a pretty prolific belief that native=crazy dangerous. Yet of course the iPhone has entirely native apps, and we've had native sandboxing and rights restrictions since...what...the creation of UNIX?
saurik 15y ago
Well, as an example, if you are using 4.0.0-3 you probably have a kernel susceptible to mempodipper (although that's "buggy", not "ancient", and it is not possible to exploit that bug from an app: you have to do it over adb). https://github.com/saurik/mempodroid https://github.com/saurik/mempodroid Regardless, it is true: most of the exploits that have been used (Rage Against the Cage, GingerBreak, zergRush) have been in user-land components (adbd, vold, libsysutils), not in the kernel. On Android 1.x, though: kernel bugs FTW.
stonemetal 15y ago
http://en.wikipedia.org/wiki/Android_version_history http://en.wikipedia.org/wiki/Android_version_history http://en.wikipedia.org/wiki/Linux_kernel#Timeline http://en.wikipedia.org/wiki/Linux_kernel#Timeline From these two it is fairly easy to tell how current the kernel is for any rev of android out there. A quick cross comparison shows that it was more or less current at time of release but isn't updated afterwards. This means there are quite a few three or four year old kernels out there since most devices are in the 2.x range. I am not sure what qualifies as ancient, but I never really had a problem with the 2.6 kernel line.