Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
IOS Cellphones Handhelds Security Software Apple

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.'
This discussion has been archived. No new comments can be posted.

iOS App Update Technique Puts Users At Risk

Comments Filter:
  • by jareth-0205 ( 525594 ) on Saturday January 30, 2016 @09:35AM (#51402441) Homepage

    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.

    • by tepples ( 727027 ) <tepples@gmail.TEAcom minus caffeine> on Saturday January 30, 2016 @10:22AM (#51402593) Homepage Journal

      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)

        by Duckman5 ( 665208 )

        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.

        • by tepples ( 727027 ) <tepples@gmail.TEAcom minus caffeine> on Saturday January 30, 2016 @12:49PM (#51403487) Homepage Journal

          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?

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

            • by tepples ( 727027 )

              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:3, Informative)

          by dissy ( 172727 )

          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

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

      • by Anonymous Coward

        Yep, that's a totally realistic solution.

      • by tlhIngan ( 30335 )

        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.

        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

        • by tepples ( 727027 )

          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.

    • by gstoddart ( 321705 ) on Saturday January 30, 2016 @11:51AM (#51403103) Homepage

      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.

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

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

        • by Fnord666 ( 889225 ) on Saturday January 30, 2016 @01:31PM (#51403725) Journal

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

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

    • by jonwil ( 467024 ) on Saturday January 30, 2016 @09:57AM (#51402511)

      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)

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

  • Next time I get whined at by middle management why iPhones are on the corporate blacklist this should do.

    • What types of phones are on the whitelist? Any phone where you can execute arbitrary code is insecure, even if it has been "vetted" by an app store. And even if you can't execute external code, it is likely insecure anyway due to bugs in the OS itself.
      • by tepples ( 727027 )

        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.

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

  • The linked article is just FUD. It basically says that using JSPatch the App can circumvent the app sandbox, and without any technical exlication. Just Fud
    • And CSO (where the article is hosted) is interested in spreading FUD about iOS "risks", they live on "analyzing" security threats and they have to identify risks even where there's no risk
  • "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.

  • A phone app can use an complicated technology to do something, which pc apps can do without any problems all the time.

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

      • by allo ( 1728082 )

        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.

  • 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?

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

    • by Aaden42 ( 198257 )

      article seems to imply that Apple's primary security model is to first verify the apps and then give them at runtime unlimited access

      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

System going down at 5 this afternoon to install scheduler bug.

Working...