Hacker News Reader

Comment by ianlevesque | Hacker News Reader

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.

View on HN

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/

You can just restart the device and the infection will disappear.

Couldn't it just 'pretend' to reboot?

Not if you hold down the power button

That's not the most reliable way to make sure it rebooted. https://blog.zecops.com/research/persistence-without-persist...

Yeah just hold it for long enough and it will reboot

i guess this is true for most and the mentioned jailbreak, but not for all?

This would require a sophisticated exploit to get around.

i'll take that as a yes

If you're worried about "all" jailbreaks, then there's no need at all to use sideloading.

i'd consider myself interested

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.

> 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.

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/fbb634c78269...

1: https://github.com/nst/iOS-Runtime-Headers/issues/32

2: https://github.com/nst/iOS-Runtime-Headers/tree/fbb634c78269...

These are all security issues that Apple fixes by moving them outside of the process.

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?

> 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.

15% up to your first million.

Reply on news.ycombinator.com