3 ms·

This is the same thing that the iPhone jailbreakers do: look for security holes to open up the window to "root" (or install another OS: http://www.idroidproject

by Xuzz 16y ago

This is the same thing that the iPhone jailbreakers do: look for security holes to open up the window to "root" (or install another OS: http://www.idroidproject.org/ http://www.idroidproject.org/) on the iPhone. The sad part is that Android is supposed to solve this problem, but (for many of the devices) it doesn't seem to change it at all.

mmastrac 16y ago
I'm not as familiar with jailbreaking the iPhone as I am with rooting Android phones, so feel free to correct me. Android is much more difficult to exploit for us because most processes don't run with the equivalent of root. Even through we're able to exploit the browser occasionally, we can't normally use that to escalate to root (there are some exceptions to this that I won't go into :)). There are system processes, but generally these important processes run as "system" rather than root. Generally, only the processes that need to setuid() to another user run as root. I believe (but I'm not sure) that the iPhone has two users: one at a root level for system processes/applications and another for installed applications. This allows the iPhone dev team to attack the browser and use that to quickly gain control of the entire device. The nice part on Android for us is having access to the adb shell, which occasionally lets us poke into things we shouldn't normally be able to poke at. Most Android root attempts happen through this shell user which is generally inaccessible to installed applications. You can see the additional groups granted to the shell user here: http://android.git.kernel.org/?p=platform/system/core.git;a=blob;f=adb/adb.c;h=0da72189fc43335636662a31ebec557483d2d7b7;hb=HEAD#l910 http://android.git.kernel.org/?p=platform/system/core.git;a=...
- Xuzz 16y ago
  That was true for iPhone OS 1.x, but since 2.0 they moved everything to 'mobile' except a few (very heavily sandboxed) daemons. For example, the 'JailbreakMe' jailbreak exploited FreeType running in the browser (Safari), but it still was sandboxed and running as 'mobile', so it had to the exploit the kernel itself -- from userland -- to get full access to the system. (It also installed itself to run at startup, using yet another exploit to evade the code signing requirements.) However, if, on an iOS device, you do find an exploit in a root process, you still don't have a way to do much. Because of the code signing requirements and the W^X protection, you can't run your own binary or even execute shellcode: ROP is the only method possible to run code. So you still have to exploit the kernel to disable those, making root code execution is only slightly more useful than 'mobile' code execution for that purpose. But that's not even really relevant, since only a few (JailbreakMe, Spirit, the on-bootup component of limera1n and greenpois0n) of the "jailbreaks" (a really misleading term, since they are more of "injected kernel patches to remove code signing requirements") are even done from a booted device at all! Most of the exploitation happens in the lower-level bootloaders, over USB (using the protocols intended for restoring the device if the higher-level components fail). Once you get access there, you can pretty much do anything you want (run a different OS, remove restrictions from the kernel), but only for this one boot cycle. After a reboot, you need to apply these patches again, leading to what's known as a "tethered jailbreak": you have to exploit the bootloaders each reboot to start up the device. This can be avoided with yet another exploit, which breaks the chain of trust at boot time to apply the patches without user intervention. Edit: some clarification. Edit 2: I should turn this into a blog post ;P.
  - mmastrac 16y ago
    Thanks for the clarification! My iPhone knowledge is horribly dated. It sounds like the iPhone security model has advanced beyond Android: there is still no sandboxing outside of uid/gid perms on Android. Much of the work we do on Android involves some of the lower-level bootloaders well. Because each of the different Android manufacturers has implemented their own bootloaders, we tend to find lots of potential exploits at that level. The work you guys do on the iPhone side is impressive.
    - Xuzz 16y ago
      iOS actually has a full implementation of Scheme (TinyScheme) running inside the kernel, that manages the (often very complex) permission schemes -- one for each type of pre-installed app or daemon, and then one for the third-party apps as well. Edit: Unrelated: I just realized you made the Treo 650 Linux version -- that was awesome!
  - nfriedly 16y ago
    I should turn this into a blog post ;P. Please do!
    - CaptainZapp 16y ago
      I second that. You really have a flair of explaining such complex issues in understandable prose.

by Xuzz 16y ago

mmastrac 16y ago

I'm not as familiar with jailbreaking the iPhone as I am with rooting Android phones, so feel free to correct me. Android is much more difficult to exploit for us because most processes don't run with the equivalent of root. Even through we're able to exploit the browser occasionally, we can't normally use that to escalate to root (there are some exceptions to this that I won't go into :)). There are system processes, but generally these important processes run as "system" rather than root. Generally, only the processes that need to setuid() to another user run as root. I believe (but I'm not sure) that the iPhone has two users: one at a root level for system processes/applications and another for installed applications. This allows the iPhone dev team to attack the browser and use that to quickly gain control of the entire device. The nice part on Android for us is having access to the adb shell, which occasionally lets us poke into things we shouldn't normally be able to poke at. Most Android root attempts happen through this shell user which is generally inaccessible to installed applications. You can see the additional groups granted to the shell user here: http://android.git.kernel.org/?p=platform/system/core.git;a=blob;f=adb/adb.c;h=0da72189fc43335636662a31ebec557483d2d7b7;hb=HEAD#l910 http://android.git.kernel.org/?p=platform/system/core.git;a=...

Xuzz 16y ago
That was true for iPhone OS 1.x, but since 2.0 they moved everything to 'mobile' except a few (very heavily sandboxed) daemons. For example, the 'JailbreakMe' jailbreak exploited FreeType running in the browser (Safari), but it still was sandboxed and running as 'mobile', so it had to the exploit the kernel itself -- from userland -- to get full access to the system. (It also installed itself to run at startup, using yet another exploit to evade the code signing requirements.) However, if, on an iOS device, you do find an exploit in a root process, you still don't have a way to do much. Because of the code signing requirements and the W^X protection, you can't run your own binary or even execute shellcode: ROP is the only method possible to run code. So you still have to exploit the kernel to disable those, making root code execution is only slightly more useful than 'mobile' code execution for that purpose. But that's not even really relevant, since only a few (JailbreakMe, Spirit, the on-bootup component of limera1n and greenpois0n) of the "jailbreaks" (a really misleading term, since they are more of "injected kernel patches to remove code signing requirements") are even done from a booted device at all! Most of the exploitation happens in the lower-level bootloaders, over USB (using the protocols intended for restoring the device if the higher-level components fail). Once you get access there, you can pretty much do anything you want (run a different OS, remove restrictions from the kernel), but only for this one boot cycle. After a reboot, you need to apply these patches again, leading to what's known as a "tethered jailbreak": you have to exploit the bootloaders each reboot to start up the device. This can be avoided with yet another exploit, which breaks the chain of trust at boot time to apply the patches without user intervention. Edit: some clarification. Edit 2: I should turn this into a blog post ;P.
- mmastrac 16y ago
  Thanks for the clarification! My iPhone knowledge is horribly dated. It sounds like the iPhone security model has advanced beyond Android: there is still no sandboxing outside of uid/gid perms on Android. Much of the work we do on Android involves some of the lower-level bootloaders well. Because each of the different Android manufacturers has implemented their own bootloaders, we tend to find lots of potential exploits at that level. The work you guys do on the iPhone side is impressive.
  - Xuzz 16y ago
    iOS actually has a full implementation of Scheme (TinyScheme) running inside the kernel, that manages the (often very complex) permission schemes -- one for each type of pre-installed app or daemon, and then one for the third-party apps as well. Edit: Unrelated: I just realized you made the Treo 650 Linux version -- that was awesome!
- nfriedly 16y ago
  I should turn this into a blog post ;P. Please do!
  - CaptainZapp 16y ago
    I second that. You really have a flair of explaining such complex issues in understandable prose.