Apple starts rejecting apps with “hot code push” features • Hacker News Board

Re: Apple starts rejecting apps with “hot code push” features

#231

Post by lmm » Wed, Mar 08, 2017, 10:30 AM UTC

scintill76 wrote: post #215

orless wrote: post #191

Earlier quoted context omitted.

I'm not buying the MITM argument in general. If remote code is downloaded via HTTPS, it could not be hijacked, at least not easily.

HTTPS is sufficient against MITM, until someone disables all verification to use their self-signed cert, or adds their poorly-secured "CA" cert to the allowed CA's for the download, or adds a weak cipher to the list. Do you trust every app developer to do those right (if they even use HTTPS!)[0], or would you rather trust Apple to get it right in the centralized system they designed for app updates for all apps? I'm…

> Do you trust every app developer to do those right (if they even use HTTPS!)[0]

If I'm running an app that includes native code and accesses data from the outside world then I'm probably trusting that app developer to write C code that doesn't contain arbitrary code execution vulnerabilities, which is much much harder than using HTTPS right.

Re: Apple starts rejecting apps with “hot code push” features

#232

Post by [deleted] » Wed, Mar 08, 2017, 10:35 AM UTC

pjc50 wrote: post #217

threeseed wrote: post #170

Earlier quoted context omitted.

To some extent yes but often no. Apple has close relationships with those companies so it's often a case of them reaching out to the developers rather than just blinding rejecting the app. But any idea that Apple would allow them to run ruff shot over the platform and do whatever they wanted is a bit ridiculous.

> ruff shot "Rough shod", before we get another mondegreen propagating across the internet.

[deleted]

Re: Apple starts rejecting apps with “hot code push” features

#233

Post by sametmax » Wed, Mar 08, 2017, 10:40 AM UTC

jamespo wrote: post #216

sametmax wrote: post #204

Earlier quoted context omitted.

It's not ridiculous, they have been doing it for a long time now. E.G: Apple uses private APIs ( http://sourcedna.com/blog/20151018/ios-apps-using-private-ap... ) to build some of their software and reject apps doing the same, effectively killing competition. But Google and facebook uses them because they want to create products that can compete with apple's features. E.G: https://daringfireball.net/2008/11/google_mo…

Do you have examples more recent than 2008?

Those are not easy to find, it's not really something they advertise and you need somebody to publicly catch them.

The only reason I know they do is because some of my friends working on mobile video games regularly complain they can't get some features because they are private while google and facebook do. They analyzed some apps to try to copy said features and realized the unfairness of their situation.

Those are lunch chit chats, not hard facts. But they got seldom reasons to lie.

Re: Apple starts rejecting apps with “hot code push” features

#234

Post by lmm » Wed, Mar 08, 2017, 10:40 AM UTC

marak830 wrote: post #113

irontoby wrote: post #101

Earlier quoted context omitted.

Games updating DLC is nothing new and is not what this is about. Google did recently change the Android permission model; previously, apps had to request all their permissions at install time and it was all-or-nothing (and frankly, hardly anyone bothered to look them over.) Now, certain permissions have to be requested when they're needed (at least for recent versions of the SDK) and the user can choose to allow or d…

See I do trust that - but only to an extent. I always wonder when seeing one update, if there is a 0 day that can bypass that. On a technical level I know I run the same risk with my PC, but at the same time, it's more difficult for me to examine processes and startups in my android.

Realistically, if they've written their own native code that parses their updates then almost certainly. If they're using an established library then maybe not (likewise if they're using a decent language, but unfortunately no-one does that). I'm reminded of the example at the bottom of http://www.gamasutra.com/view/feature/194772/dirty_game_deve... where the game had a buffer overflow in displaying its own EULA.

Re: Apple starts rejecting apps with “hot code push” features

#235

Post by jonathanstrange » Wed, Mar 08, 2017, 10:41 AM UTC

eeeeeeeeeeeee wrote: post #154

adjunct wrote: post #98

I'm Erez Rusovsky, the CEO of Rollout.io Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps. We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism…

No, what you end up doing is effectively destroying the security protections Apple puts in place to protect the user from unknown/bad code from running on their device. Apple signs apps for a reason -- now we have to trust you to deliver that code safely to the user without being manipulated in transit. I also have to trust that you will respect my privacy. And I don't. It also seems clearly against their EULA, so yo…

now we have to trust you to deliver that code safely to the user without being manipulated in transit.

You have to trust app developers anyway, since they run native code on your machine. While there are security concerns, these are not the real motivation. Apple is gradually closing down their platform, as many people have predicted in the past. You can also see that in various subtle changes to Gatekeeper and the Sandboxing features.

For me personally, the red line is when unsigned executables can no longer run on MacOS. If Apple ever disallows unsigned executables, I will immediately discontinue my application on MacOS and redirect customers who rely on it to Apple's customer support.

Re: Apple starts rejecting apps with “hot code push” features

#236

Post by jacobolus » Wed, Mar 08, 2017, 10:42 AM UTC

pjc50 wrote: post #217

threeseed wrote: post #170

Earlier quoted context omitted.

To some extent yes but often no. Apple has close relationships with those companies so it's often a case of them reaching out to the developers rather than just blinding rejecting the app. But any idea that Apple would allow them to run ruff shot over the platform and do whatever they wanted is a bit ridiculous.

> ruff shot "Rough shod", before we get another mondegreen propagating across the internet.

To be more precise, the idiom is typically “ride roughshod over” rather than “run ...”, and roughshod is typically written as one word.

Roughshod means the horseshoes have their nails sticking out the bottom to help prevent slipping, so you can imagine trampling someone with those could be painful.

Re: Apple starts rejecting apps with “hot code push” features

#237

Post by prabodhprakash » Wed, Mar 08, 2017, 10:44 AM UTC

jameside wrote: post #135

teknologist wrote: post #93

Earlier quoted context omitted.

This appears to affect apps using JSPatch which is not pushing Objective-C but JavaScript. Source: https://github.com/bang590/JSPatch/issues/746 (in Chinese)

The key part of JSPatch is that it exposes arbitrary, uncontrolled access to native APIs. You could use it to call private APIs even because Objective-C doesn't distinguish between public and private APIs at runtime, so Xcode's compiler checks and Apple's static analysis can't anticipate which APIs are possibly called. In contrast, React Native doesn't expose uncontrolled access to native APIs. You write regular Obje…

"You write regular Objective-C methods that are callable from JavaScript," - the objC function that I am calling from JS can be capable of calling a private API received by it in an argument - that breaks the entire claim of reactNative not supporting calls to private API. React Native must also go down.

Re: Apple starts rejecting apps with “hot code push” features

#238

Post by bigiain » Wed, Mar 08, 2017, 10:44 AM UTC

scintill76 wrote: post #215

orless wrote: post #191

Earlier quoted context omitted.

I'm not buying the MITM argument in general. If remote code is downloaded via HTTPS, it could not be hijacked, at least not easily.

HTTPS is sufficient against MITM, until someone disables all verification to use their self-signed cert, or adds their poorly-secured "CA" cert to the allowed CA's for the download, or adds a weak cipher to the list. Do you trust every app developer to do those right (if they even use HTTPS!)[0], or would you rather trust Apple to get it right in the centralized system they designed for app updates for all apps? I'm…

"HTTPS is sufficient against MITM, until someone disables all verification to use their self-signed cert, or adds their poorly-secured "CA" cert to the allowed CA's for the download, or adds a weak cipher to the list. "

Or that attacker controls or can coerce a Certificate Authority in the OS's root list - like, say, just about any nation state...

Most apps - I suspect - are not pinning their TLS certs. Apple have already gotten onto a very public fight with the FBI.

Re: Apple starts rejecting apps with “hot code push” features

#239

Post by robk » Wed, Mar 08, 2017, 10:51 AM UTC

algesten wrote: post #195

Angostura wrote: post #159

Earlier quoted context omitted.

The only app I've got that appears to actually update itself without going through the AppStore is the HSBC mobile banking app. I'd be interested in hearing the discussions going on between Apple and HSBC at the moment.

Judging by how sluggish and annoying the HSBC app is, I think it is a web app framed in a thin launcher from the app store. I.e. it downloads a bunch of javascript/html/css and that executes within a UIWebView/WKWebView. Using caching and localStorage, you can construct such an app to not need to download everything on each launch. The reason that's allowed is because everything executes within a sandboxed browser en…

Is it possible to do that and use the fingerprint sensor for login in a secure way? I thought the same as you until they enabled Touch login.

Re: Apple starts rejecting apps with “hot code push” features

#240

Post by menckenjr » Wed, Mar 08, 2017, 10:51 AM UTC

jameside wrote: post #103

dilipray wrote: post #76

"Hi there -- I believe that title isn't quite accurate; Apple specifically is referring to behavior of a library called Rollout which lets people dynamically inject Objective-C/Swift. They are doing hot delivery of native, Objective-C code. It's really not about React Native nor Expo. Expo (and the React Native library we use) doesn't do any of that. We also make sure we don't expose ways to dynamically execute nativ…

Hi, I work on Expo (YC S16) and also am a core contributor to React Native. Apple's message reads to me that they're concerned about libraries like Rollout and JSPatch, which expose uncontrolled and direct access to native APIs (including private APIs) or enable dynamic loading of native code. Rollout and JSPatch are the only two libraries I've heard to be correlated with the warning. React Native is different from t…

This needs a little elaboration. Cached Javascript in any hybrid app is a security hole because that can be exposed through a jailbreak. Depending on how much of your business logic you've pushed into the JS layer to enable that "80% code sharing" that makes managers go all tingly you may be exposing all kinds of things - cached access tokens, API keys and whatnot - to anyone who wants to install your app and mine its secrets.