Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

461–470 of 498 posts

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

#461

Earlier quoted context omitted.

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…

Security on iOS comes from the sandboxing that all apps run in. Apple's review process is really quick and adds approximately nothing in terms of security. Apps running in the sandbox should be safe no matter how evil they are, and if they can break out, the proper solution is to fix the sandbox.

I wasn't even talking about breaking out of the sandbox. Also, at the most basic level, simply having a trusted and signed delivery process of binaries does add some security. Nobody here is saying it will prevent a compromise, but since when is security viewed like this? It's about layers of protection.

Reminds me of people fussing about getting root on a workstation. Simply getting access to the user's account, without root, will be hugely damaging. Plus you'll likely have root in no time after you get that user account.

And the review process isn't even entirely about stopping the attack. If the malicious code was in the app, when it was submitted for review, you can at least have a trail and can review it later to see how it happened.

If the attack happened with this specific app framework, the bad code could be dynamically loaded into memory and then purged, so you'd never know what happened.

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

#462

What will happen to YouTube? YouTube has been pushing new functionality ahead of updates for me recently. For example, the new "double tap to rewind 10 seconds" feature appeared at random one day (without an any updates)...then eventually the feature is announced in an App Store update. Or is the app review process more subjective?

The iPhone also has the ability to automatically update apps in the background if you allow it.

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

#463

Earlier quoted context omitted.

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 S…

Yes, you have to trust the app developer. And Apple is acting as a check/oversight on that relationship, too. Whether it's of use or not, that is really another discussion.

That is my personal red line also. But I am 100% in support of them enforcing signed apps for the majority, but it should be something you can turn off for advanced users via firmware/bios. My mom does not need to run unsigned apps she finds on the Internet.

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

#464

Earlier quoted context omitted.

Security on iOS comes from the sandboxing that all apps run in. Apple's review process is really quick and adds approximately nothing in terms of security. Apps running in the sandbox should be safe no matter how evil they are, and if they can break out, the proper solution is to fix the sandbox.

I wasn't even talking about breaking out of the sandbox. Also, at the most basic level, simply having a trusted and signed delivery process of binaries does add some security. Nobody here is saying it will prevent a compromise, but since when is security viewed like this? It's about layers of protection. Reminds me of people fussing about getting root on a workstation. Simply getting access to the user's account, wit…

If you don't break out of the sandbox then you can't access anything interesting.

Traditional UNIXoid workstations are quite different. A program running under your user can do anything your user can do. It can access and delete all of your data.

An iOS app can't access or delete any of your data by default. Everything requires explicit permissions granted by the user, and even those are pretty limited. As long as the sandbox functions correctly, a malicious app will never be able to, say, read my financials spreadsheet out of Numbers, or my private texts out of Messages.

I've yet to see any evidence that this process adds security. Given that the review process is extremely shallow (some automated tools are run to scan for private API calls and such, and two non-experts spend a total of about ten minutes with your app) so there's no hope of any sort of useful security audit being done.

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

#465

Earlier quoted context omitted.

So it is claimed in civics classes, but that's a rather narrow interpretation of "create law".

I'm not sure what other definition there is...

'globox nailed it upthread.

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

#466

Earlier quoted context omitted.

Does this still work? A cursory googling says it was deprecated in iOS 9 betas but may have been re-enabled?

Depreciated is not removed. Apple is usually very conscientious about depreciating things, then waiting a while before removing them. In some cases they have gone to great lengths... for example the now 5 year depreciation of OpenSSL: first they marked it depreciated, which generates a compiler warning, then after a few years they removed the headers from the MacOS SDK so you couldn't compile new software but left th…

Poor choice of words then, it was deprecated and removed over the course of iOS 9 betas, with the plan to make a new system only available to "captive network apps" that could declare a specific list of SSIDs that they manage. Appears they backtracked though? I didn't see any recent info.

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

#467
post #217

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.

I always thought they were Eggcorns.

http://eggcorns.lascribe.net/

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

#468
post #288

Earlier quoted context omitted.

Depends on who you're expecting the MiTM attack to be executed by. Are _you_ secured against, say, an attacker who works at Verisign and can create a valid cert for api.yourdomain.com? Or an attacker who has a buddy who works at GoDaddy who can subvert your dns records so they can trick LetsEncrypt into issuing a valid cert for api.yourdomain.com? Or an elbonian teenage hacker who's just got your AshleyMaddison asswo…

And all of this is "easily"?

Like I said - depends on who you are.

For me? Not really "easily" (tho a wifi pineapple in a coffee shop where FE Devs hang out attempting to MiTM them with the Charlesproxy root CA would be a fun experiment... Which, of course, I'd never do - because that'd be bad, right?)

For someone at the NSA or CIA or Mossad? Sure it's easy. For someone a little further down the LEO "cyber" chart like FBI, probably not "easy". For a local beat cop or council dog catcher - nah, definitely not "easy".

For a very-dark-grey pen tester or redteam who're prepared to phish your email password and use it to p0wn your dns registrar? They'd probably call that "easy"... (Hell, I've got a few pentesting friends who'd call that "fun"!)

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

#469

Earlier quoted context omitted.

> You blog sounds like the PR spin that came out of Aereo, a company that spent an inordinate amount of effort to stay within the absolute letter of a law. Without reading the blog, I just wanted to comment on Aereo: a lot of us think that this was the wrong decision, and not in a facetious or 'cute' way. To quote Scalia's dissent in the case: > In a dissent that expressed distaste for Aereo’s business model, Justice…

This is obviously getting off topic, but in a common law system that interpretation is just wrong. The law is an evolving thing, it is meant to be interpreted, read, and understood, not to be exploited.

If the law is very clear, then the court should not need to do any interpretation. In those cases it just applies it.

In the Aereo case, the law was clear. The court was supposed to uphold the law, but didn't.

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

#470
post #128

Earlier quoted context omitted.

It's legal in many cities.

It's become legal (after the fact) in several cities, and Uber has allegedly intentionally attempted to subvert attempts by law enforcement to investigate their operations.

Some cities it was legal to begin with, btw.
Post reply on HN