4 ms·

You're conflating a whole bunch of issues. iOS enforces the same sandbox on all installed apps, whether they were installed from the App Store, or using a devel

You're conflating a whole bunch of issues. iOS enforces the same sandbox on all installed apps, whether they were installed from the App Store, or using a developer or even enterprise distribution certificate. Opening up to competing App Stores, or allowing 'untrusted' sources, doesn't weaken this security posture. You'd still have to grant permissions to said 3rd party apps, and the kind of low level access you're talking about isn't even able to be granted without an exploit. If you have an exploit, then the current requirement to use Xcode to install your exploit code, isn't stopping anyone even today. Apple's restrictions exist to protect their 30% cut of all software revenue. Any other benevolence you perceive to be there is naive.

SV_BubbleTime 3y ago
15% up to your first million.
threeseed 3y ago
App Store has a number of manual and automated checks. One of which is checking for private API usage which would allow developers to cause all sorts of unchecked havoc. And because of the way Objective-C apps work i.e. dynamic dispatch you can't statically check for it in the binary when the app is launched. Nor can you realistically check it at runtime since that code path is the hottest there is and needs to be highly optimal. I suspect that there will be an App Store SDK that third party stores will need to use that incorporates these sort of checks.
- ianlevesque 3y ago
  > which would allow developers to cause all sorts of unchecked havoc. This is simply not true. The security boundary is not at that layer. Calling private methods doesn't escape the sandbox.
  - judge2020 3y ago
    Sure, but private methods are another vector - tracking and bypassing the IDFA and potentially acting as official Apple Apps to use/abuse things like Carrier/SIM info[0], updating the wallpaper for the user[1], accessing call history[2], etc. 0: https://github.com/nst/iOS-Runtime-Headers/blob/fbb634c78269b0169efdead80955ba64eaaa2f21/Frameworks/CoreTelephony.framework/CTMobileEquipmentInfo.h#L10 https://github.com/nst/iOS-Runtime-Headers/blob/fbb634c78269... 1: https://github.com/nst/iOS-Runtime-Headers/issues/32 https://github.com/nst/iOS-Runtime-Headers/issues/32 2: https://github.com/nst/iOS-Runtime-Headers/tree/fbb634c78269b0169efdead80955ba64eaaa2f21/PrivateFrameworks/CallHistory.framework https://github.com/nst/iOS-Runtime-Headers/tree/fbb634c78269...
    - saagarjha 3y ago
      These are all security issues that Apple fixes by moving them outside of the process.
- ChadNauseam 3y ago
  If you can't statically check for it, how does the app store check for it? Do they just open up the app and poke around with the runtime-private-api-detector enabled?
judge2020 3y ago
Nearly all jailbreaks since iOS ~5~ 9[0] (besides checkm8 for A11 and earlier devices) have been via sideloading an app and running an exploit chain of sandbox escape->kernel exploit->some form of r/w mounting root (amongst other steps). The attack surface for the sandbox is so large it's basically impossible to ensure absolutely nothing bad happens inside it. After some exploit gets patched is when all the inventory sitting in logistics become at risk of interception and compromise. 0: https://canijailbreak.com/ https://canijailbreak.com/
- saagarjha 3y ago
  You can just restart the device and the infection will disappear.
  - sambazi 3y ago
    i guess this is true for most and the mentioned jailbreak, but not for all?
    - saagarjha 3y ago
      This would require a sophisticated exploit to get around.
      - sambazi 3y ago
        i'll take that as a yes
        Dylan16807 3y ago
        If you're worried about "all" jailbreaks, then there's no need at all to use sideloading.
        sambazi 3y ago
        i'd consider myself interested
TerrifiedMouse 3y ago
> Apple's restrictions exist to protect their 30% cut of all software revenue. They don't need the App Store to do that. Xbox and Playstation have retail stores selling their software and they get a cut all the same because if they refuse to sign your game executable ... it won't run on end user machines.

SV_BubbleTime 3y ago

15% up to your first million.

threeseed 3y ago

App Store has a number of manual and automated checks. One of which is checking for private API usage which would allow developers to cause all sorts of unchecked havoc. And because of the way Objective-C apps work i.e. dynamic dispatch you can't statically check for it in the binary when the app is launched. Nor can you realistically check it at runtime since that code path is the hottest there is and needs to be highly optimal. I suspect that there will be an App Store SDK that third party stores will need to use that incorporates these sort of checks.

ianlevesque 3y ago
> which would allow developers to cause all sorts of unchecked havoc. This is simply not true. The security boundary is not at that layer. Calling private methods doesn't escape the sandbox.
- judge2020 3y ago
  Sure, but private methods are another vector - tracking and bypassing the IDFA and potentially acting as official Apple Apps to use/abuse things like Carrier/SIM info[0], updating the wallpaper for the user[1], accessing call history[2], etc. 0: https://github.com/nst/iOS-Runtime-Headers/blob/fbb634c78269b0169efdead80955ba64eaaa2f21/Frameworks/CoreTelephony.framework/CTMobileEquipmentInfo.h#L10 https://github.com/nst/iOS-Runtime-Headers/blob/fbb634c78269... 1: https://github.com/nst/iOS-Runtime-Headers/issues/32 https://github.com/nst/iOS-Runtime-Headers/issues/32 2: https://github.com/nst/iOS-Runtime-Headers/tree/fbb634c78269b0169efdead80955ba64eaaa2f21/PrivateFrameworks/CallHistory.framework https://github.com/nst/iOS-Runtime-Headers/tree/fbb634c78269...
  - saagarjha 3y ago
    These are all security issues that Apple fixes by moving them outside of the process.
ChadNauseam 3y ago
If you can't statically check for it, how does the app store check for it? Do they just open up the app and poke around with the runtime-private-api-detector enabled?

judge2020 3y ago

Nearly all jailbreaks since iOS ~5~ 9[0] (besides checkm8 for A11 and earlier devices) have been via sideloading an app and running an exploit chain of sandbox escape->kernel exploit->some form of r/w mounting root (amongst other steps). The attack surface for the sandbox is so large it's basically impossible to ensure absolutely nothing bad happens inside it. After some exploit gets patched is when all the inventory sitting in logistics become at risk of interception and compromise. 0: https://canijailbreak.com/ https://canijailbreak.com/

saagarjha 3y ago
You can just restart the device and the infection will disappear.
- sambazi 3y ago
  i guess this is true for most and the mentioned jailbreak, but not for all?
  - saagarjha 3y ago
    This would require a sophisticated exploit to get around.
    - sambazi 3y ago
      i'll take that as a yes
      - Dylan16807 3y ago
        If you're worried about "all" jailbreaks, then there's no need at all to use sideloading.
        sambazi 3y ago
        i'd consider myself interested

TerrifiedMouse 3y ago

> Apple's restrictions exist to protect their 30% cut of all software revenue. They don't need the App Store to do that. Xbox and Playstation have retail stores selling their software and they get a cut all the same because if they refuse to sign your game executable ... it won't run on end user machines.