iOS App Update Technique Puts Users At Risk (csoonline.com) 67
itwbennett writes: An increasing number of iOS application developers use a technique that allows them to remotely modify the code in their apps without going through Apple's normal review process, potentially opening the door to abuse and security risks for users. An implementation of this technique, which is a variation of hot patching, comes from an open-source project called JSPatch. After adding the JSPatch engine to their application, developers can configure the app to always load JavaScript code from a remote server they control. This code is then interpreted by the JSPatch engine and converted into Objective-C. 'JSPatch is a boon to iOS developers,' security researchers from FireEye said in a blog post. 'In the right hands, it can be used to quickly and effectively deploy patches and code updates. But in a non-utopian world like ours, we need to assume that bad actors will leverage this technology for unintended purposes.'
Brought it on themselves (Score:4, Insightful)
I have to think that Apple have brought this kind of thing on themselves - their ridiculous app approval system is uncertain and slow and developers are obviously going to try to find a way round it. If I find a bug in Android I fix it and release it. My iOS counterparts often have to live with the bug for weeks before they release because of the faff of the approval process.
Re:Brought it on themselves (Score:4, Insightful)
You could distribute your app as source code under a free software license and allow iOS device users who also own a Mac to install the fix right away. Since Xcode 7, Apple has stopped requiring each individual user to buy a $99 per year developer license just to test an app compiled on his own Mac on his own iOS device.
Re: (Score:3, Insightful)
You could distribute your app as source code under a free software license and allow iOS device users who also own a Mac to install the fix right away.
Please tell me you're kidding. These are iOS users we're talking about. They have purposely chosen the "easy to use" OS (even with all its limitations). Like hell you're going to get them to figure out how to compile an app
Not only that, in order to run XCode you need to have a Mac. You just went from a $200-$600 investment in the iPhone/iPad and added a thousand dollars to it. There are no shortage of iOS users with Windows machines who like their iDevice but aren't ready to make that leap to a Mac.
Re:Brought it on themselves (Score:4, Insightful)
I'm not kidding that it's possible. In fact, several developers of iOS apps that do things forbidden by the App Store Review Guidelines, such as classic game console emulators or WLAN troubleshooting apps, have chosen this route of requiring a Mac for installation. But I agree with you that it's unrealistic for the majority of users.
and added a thousand dollars to it
The last time I checked Apple.com, a Mac mini started at 499 USD plus tax. Where do you get this "thousand dollars", unless you live in a country whose dollar happens to have such an exchange rate with the USD?
Mac + display, keyboard, and mouse = $529 (Score:3)
I suppose the users are going to use some combination of telepathy and telekinesis to use that computer without a keyboard, mouse and monitor?
The last time I checked Apple.com, a Mac mini started at 499 USD plus tax, to which one can add either A. the display, keyboard, and mouse of one's existing non-Mac PC or B. one's existing HDMI TV and a 30 USD keyboard and mouse, bringing the total to 529 USD. This is still well shy of the $1,000 that Duckman5 quoted.
Not to mention the router and other network hardware and ISP costs they'll incur while trying to get the thing onto the internet to download a compiler and the source code.
I was assuming someone who already owns an Internet-connected PC running Windows or X11/Linux and an iPhone or iPad and is looking to replace the PC running Windows or X11/Linux with a Mac in o
Re: (Score:2)
The last time I checked Apple.com, a Mac mini started at 499 USD plus tax. Where do you get this "thousand dollars", unless you live in a country whose dollar happens to have such an exchange rate with the USD?
To be quite honest, I didn't even know that Apple even offered the mini anymore. I don't really shop Apple very often.
I think that's a bit of a strawman, though. You could just as easily suggest that someone buy a used or refurb unit. The point still remains that it's unreasonable to expect people to invest in an entirely new computer, learn to use it, and learn how to use XCode just to run an app on their iDevice.
Re: (Score:2)
it's unreasonable to expect people to invest in an entirely new computer
Thank you. Can I quote you on this in case the issue comes up with someone else?
Re: (Score:2)
Re: (Score:3, Informative)
Your post is either a standard Apple troll, or you are just purposely being dense.
Please tell me you're kidding. These are iOS users we're talking about. They have purposely chosen the "easy to use" OS (even with all its limitations).
WE are talking about iOS users, but I'm not sure you are on the same page...
Like hell you're going to get them to figure out how to compile an app
Are you seriously arguing Mac users are too stupid to double click one icon? Trollolol?
Not only that, in order to run XCode you need to have a Mac.
That's very likely why he said: and allow iOS device users who also own a Mac
Or put another way, no you are very incorrect. If one already owns a Mac, there is no need for any additional Mac computers. Just the one will do.
I suppose you bought your Android phone
Perhaps the point was too few Mac users (Score:2)
Not only that, in order to run XCode you need to have a Mac.
That's very likely why he said: and allow iOS device users who also own a Mac
Just a guess, but let me try to be fair to Duckman5. I read the post as implying a claim that most iOS device users do not in fact already own a suitable Mac. Therefore my suggestion would apply to so few users that relying on it would not be worthwhile.
If one already owns a Mac, there is no need for any additional Mac computers. Just the one will do.
Unless the existing Mac is too old to run Xcode 7.
Re: (Score:1)
Yep, that's a totally realistic solution.
Re: (Score:2)
Has anyone asked RMS about this? I mean, a proprietary operating system allowing proprietary apps to use a proprietary approval method AND allowing open-source apps at the same time by sidel
Re: (Score:2)
Apple's policy with Xcode 7 sort of resembles the LibreJS browser extension that FSF promotes, which acts like NoScript except whitelisting all free scripts, except that Apple requires a $499 dongle (a Mac mini) to compile the apps.
Re:Brought it on themselves (Score:5, Insightful)
By the same token, I'm not going to trust an app which decides it's going to silently update itself without telling me.
I think it's high on the "software-asshole meter". It says "we'll do anything on your device we choose", and I'm sorry to say, but it's my fucking device.
And since this has huge potential for security exploits and other malicious acts, it's a big risk for users that may not even know it's there.
I'm pretty sure unless you explicitly set Android to automatically update stuff your fix isn't going to get pushed to my device without me knowing it ... and enabling auto-updates is something Microsoft and host of others have demonstrated is idiotic.
Because you really can't trust people who expect to just do a quick fix when nobody is looking. Because in my experience that usually means the software was poorly tested and pushed out the door.
Apple app approval may be "ridiculous" to you, but it beats the alternative of malware, or poorly thrown together code.
Boo hoo, you need to wait weeks ... software cycles used to be FAR longer than that, and overall quality has suffered. Because people expect to push out a steaming turd every few weeks and call themselves agile.
I view software which bypasses approved update mechanisms and just does it in the background as little more than trojans and malware.
Re: Brought it on themselves (Score:3)
Well you thought wrong. Google Play Services automatically and silently updates itself with no user interaction. The only way to stop it is to disable it completely, but this also breaks that use its APIs. Most Android apps don't/can't update update silently, but Play Services definitely can and does unless you go out of your way to stop it.
Re: (Score:2)
Apple app approval may be "ridiculous" to you, but it beats the alternative of malware, or poorly thrown together code.
This. EXACTLY this!
I hope that Apple changes the iOS App Store approval process to look for this insanely-dangerous BACKDOOR, and make the inclusion of that cause for instant REJECTION of the App.
Just like with Encryption backdoors, there is NO WAY this won't be exploited in 3...2...1...
Re:Brought it on themselves (Score:4, Insightful)
I hope that Apple changes the iOS App Store approval process to look for this insanely-dangerous BACKDOOR, and make the inclusion of that cause for instant REJECTION of the App.
I'm curious when exactly they changed their policy in the first place. Apple used to reject any application that tried to do anything like this.
Re: (Score:1)
I hope that Apple changes the iOS App Store approval process to look for this insanely-dangerous BACKDOOR, and make the inclusion of that cause for instant REJECTION of the App.
I'm curious when exactly they changed their policy in the first place. Apple used to reject any application that tried to do anything like this.
I would bet they haven't changed their policy. This is either a b.s. Story, or something that has slipped past Apple (until now).
Re: (Score:1)
They have not changed their policy. They have always allowed html / JavaScript content to be loaded. The hooks for JavaScript to access native functions is directly enabled in official APIs and has been used in Phonegap and the like for years. None of this is new. It may always have been possible to hide unused JS hooks in an app and remotely update JavaScript to use them. But this development methodology has been specifically endorsed for YEARS by Apple. What they don't allow is arbitrary code to be loaded i.e. users loading new code. Users can run their own code if they write it or copy / paste it. See the Pythonista app and its history. Apps generally have to point internally to the external JS code to load. Though that could point to additional code to load. Apple can and has shut it down if it gets too close to being 1) too close to an alternative App Store or 2) a source of abuse of policy or security by the developer.
So this is a vestige of the pre App Store days? Interesting!
Re: (Score:2)
Amd software has far less budget than it used to, and people expect more and quicker and cheaper. I'm not sure how you expect to vet every app update anyway, it's not like you could vet the original code so what really can you say about updates. Software used to have long release cycles. It also used to cost 10s of dollars, and have testers. Your average $1 or free app is not gonna be able to do that.
Re: (Score:2)
It takes more like 2-4 hours before the update is rolled out by Google. I believe they run some tests on your update before they let it through.
Re: (Score:1)
You do understand that this is how software use to be, right?
The company in question puts their software on their own website and "rubber stamps" their own updates.
Even the most stringent QA will miss things... users behave and use it differently quite frequently.
Yeah, I understand that is how software used to be... When a loaf of bread was fifty cents (U.S.), cars all had carbeurators, and lot of TVs still had vacuum tubes (other than the CRT).
Oh, and before everyone and his dog wasn't trying to steal your personal info off your smartphone through the internet; because smartphones didn't exist, the "internet" was still called DARPAnet, and China was still an agrarian society...
Times change. Sometimes that means old habits have to, too.
For example, Microsoft w
How long before Apple rejects (Score:2)
Re:How long before Apple rejects (Score:5, Informative)
Apps using JSPatch are already violating the app store rules anyway. Apple prohibits any app that downloads unapproved code from somewhere and runs it (or did last time I checked)
Re: (Score:2)
Apps using JSPatch are already violating the app store rules anyway. Apple prohibits any app that downloads unapproved code from somewhere and runs it (or did last time I checked)
Yes, the question appears to be "Is Apple rejecting such apps?" TFA states developers are currently using it so the answer a[[ears to be No; so I wonder if Apple is simply not looking for JSPatch or has decided to let it go.
Re: (Score:2)
You are completely incorrect. Only Webkit or JavaScriptCore components may execute dynamically-retrieved, remote code.
Per Apple's iOS Developer Program Agreement:
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided t
Thanks (Score:2)
Next time I get whined at by middle management why iPhones are on the corporate blacklist this should do.
Re: (Score:2)
Re: (Score:2)
What types of phones are on the whitelist?
Presumably company-owned wired phones that connect to the company's internal PBX or VoIP or whatever. My current employer allows BYOD, but I know of a lot of employers that don't. At non-BYOD workplaces, employees' cell phones go in a locker at the start of the shift and remain in the locker until the end of the shift.
Re: (Score:2)
Sorry, that information is not available. :)
In a nutshell, the list is VERY tiny. And unless you really spend a lot of time doing mobile auditing, you probably won't recognize half of them.
Re: (Score:2)
Yeah, the "converted into Objective-C" doesn't make any sense.
What it seems to actually be doing is creating an interface between Obj-C and JavaScript so that JS can call out to any Obj-C method, and can override any method as well to call into JavaScript code. Combined with converting Obj-C code into JavaScript, you can effectively patch existing (compiled) Obj-C code with downloaded JavaScript.
This probably went undetected in the review process because it just looks like a call to execute some sandboxed
Re: (Score:2)
Hybrid apps would have a well defined interface that the loadable code can use, with it being well isolated otherwise. This goes well beyond that, allowing the entire app to be rewritten (for example, allowing it to load arbitrary code to execute, bypassing the app store entirely).
Article is a piece of crap... (Score:2)
Re: (Score:1)
Nonsense (Score:2)
"Total nonsense!!! The brilliant technical minds creating our computer software, firmware and hardware would NEVER (cough ... sputter .. ) put users at risk"
Maybe if I practice that over and over maybe 50 or 100 times , I'll be able to get that out with a straight face.
How dangerous (Score:2)
A phone app can use an complicated technology to do something, which pc apps can do without any problems all the time.
Re: (Score:2)
A phone app can use an complicated technology to do something, which pc apps can do without any problems all the time.
Yeah.
An Android or iOS app can silently download a patch that will do bad things with the data that you have created using that particular app. It can also spy on you if you have previously given it permission to do so.
A PC app can silently download a patch that will do bad things with all of your data. It can also spy on you.
Re: (Score:2)
So the problem is trust. And that's a problem of app stores. Both google and apple suggest, that everything from their app store is safe. If they would label it just like a typical download site, the people would mistrust a bit more. And stop installing all the legal adware and spyware, which is seen as normal on mobile devices.
Re: (Score:2)
I think the ecosystem, the preinstallation and so on are asserting most users, that it's safe.
On the other hand, most PC software from not too shady sources (even warez) are pretty safe, while mobile developers seem to build adware and/or spyware without any doubts by default. I think its a mixture of claiming a new software ecosystem, which doesn't have any rules yet and the typical mobile device users, which sees his phone/tablet as consumer device like a tv and not like a computer. Realizing that somethi
Just exposes the APIs in Javascript (Score:2)
How is this different from what you can do with Cordova and Appcelerator? These frameworks allow you to create new plugins to expose any iOS APIs you want to Javascript and can load Javascript remotely.
I assume that the app cannot access any functionality that was not enabled during the App Store submission, though I'm not sure of that. Anyone any insights regarding this?
No permissions enforced at runtime? (Score:2)
This article seems to imply that Apple's primary security model is to first verify the apps and then give them at runtime unlimited access to the system, trusting them to only do the things they promised. This seems odd, especially compared with Android, where apps are limited at runtime to whatever capabilities they were granted by the user.
This issue could be trivially solved by enforcing permissions at runtime.
Re: (Score:2)
The implication (which I agree is what I got reading the article) is utterly false. Many sensitive API's are secured in the runtime sandbox by the presence of crytographically signed "entitlements." Apple won't approve an entitlement unless the app has a legitimate need for it. Calling those secured API's through any mechanism when the app bundle lacks the necessary entitle