Slashdot Mirror

← Back to Stories (view on slashdot.org)

iOS App Update Technique Puts Users At Risk (csoonline.com)

Posted by timothy on from the key-under-the-doormat dept.

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

42 of 67 comments (clear)

  1. Brought it on themselves by jareth-0205 · · Score: 3, 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.

    1. Re:Brought it on themselves by tepples · · 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. 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.

    2. Re:Brought it on themselves by gstoddart · · Score: 4, 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.

      --
      Lost at C:>. Found at C.
    3. Re:Brought it on themselves by Duckman5 · · Score: 2, 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.

    4. Re: Brought it on themselves by _merlin · · Score: 2

      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.

    5. Re:Brought it on themselves by Anonymous Coward · · Score: 1

      Yep, that's a totally realistic solution.

    6. Re:Brought it on themselves by macs4all · · 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...

    7. Re:Brought it on themselves by tepples · · Score: 3, 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?

    8. Re:Brought it on themselves by jareth-0205 · · Score: 1

      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.

    9. Re:Brought it on themselves by Fnord666 · · Score: 3, 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.

      --
      'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
    10. Re:Brought it on themselves by Duckman5 · · Score: 1

      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.

    11. Re:Brought it on themselves by macs4all · · 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).

    12. Re:Brought it on themselves by dissy · · Score: 2, 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 to make phone calls, then went right out to buy two or three more Android phones due to your thinking that one of the things somehow wasn't enough?

      You just went from a $200-$600 investment in the iPhone/iPad and added a thousand dollars to it.

      If you purchase no computer, you will spend $0. How are you arguing not buying a second computer costs thousands of additional dollars?

      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.

      Hate to have to be the one to tell you this but MacOS is not Windows, and Windows is not MacOS.

      He clearly stated this option is only for Mac users. Why do you feel the need to repeat what was already said and specifically name Windows users as excluded?
      You forgot to mention Linux users can't do this either, nor can QNX users, nor can Mainframe users...

      Quit being dense or try to troll somewhat intelligently next time.

    13. Re: Brought it on themselves by macs4all · · 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!

    14. Re:Brought it on themselves by tepples · · Score: 1

      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?

    15. Re:Brought it on themselves by tlhIngan · · Score: 1

      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 sideloading it? And enforcing open-source-ness?

      (Yes, Apple told f.lux developers they couldn't use this method because all they did was wrap their binaries around a dummy source code build. So Apple is fine if you distribute source code, but not fine if you use it to distribute binaries.)

      The mind boggles.

    16. Re:Brought it on themselves by tepples · · Score: 1

      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.

    17. Re:Brought it on themselves by Aaden42 · · Score: 1

      How many people could even afford enough wheelbarrows to carry the amount of cash they'd need to buy a Mini. Or an iPhone for that matter...

  2. How long before Apple rejects by Registered+Coward+v2 · · Score: 1

    apps using JSPatch?

    --
    I'm a consultant - I convert gibberish into cash-flow.
    1. Re:How long before Apple rejects by jonwil · · 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)

    2. Re:How long before Apple rejects by Registered+Coward+v2 · · Score: 1

      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.

      --
      I'm a consultant - I convert gibberish into cash-flow.
    3. Re: How long before Apple rejects by null+etc. · · Score: 1

      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 that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.

  3. Thanks by Opportunist · · Score: 1

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

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    1. Re:Thanks by 110010001000 · · Score: 1

      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.

    2. Re:Thanks by tepples · · Score: 1

      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.

    3. Re:Thanks by Opportunist · · Score: 1

      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.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  4. Article is a piece of crap... by fabrica64 · · Score: 2

    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

    1. Re:Article is a piece of crap... by fabrica64 · · Score: 1

      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

  5. Nonsense by vtcodger · · Score: 1

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

    --
    You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
  6. How dangerous by allo · · Score: 1

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

    1. Re:How dangerous by rasmusbr · · Score: 1

      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.

    2. Re:How dangerous by allo · · Score: 1

      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.

    3. Re: How dangerous by allo · · Score: 1

      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 something read your private data comes later.

  7. Re:Weird by rasmusbr · · Score: 1

    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.

  8. Mac + display, keyboard, and mouse = $529 by tepples · · Score: 2

    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 order to receive updates to a particular Free program before App Store users receive them. How would an iPod touch or iPad user use the App Store anyway without paying "router and other network hardware and ISP costs"?

  9. Just exposes the APIs in Javascript by sc0rpi0n · · 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?

  10. Re:Converted into Obj-C? by tricorn · · Score: 1

    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 JavaScript, not something that has full access to the dispatch tables of Obj-C classes.

  11. No permissions enforced at runtime? by l2718 · · Score: 1

    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.

    1. Re:No permissions enforced at runtime? by Aaden42 · · Score: 1

      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 entitlement just fails. Entitlement-secured API's include background execution and iCloud access among others.

      Other less-sensitive APIs such as photos/camera access, microphone access, contacts, calendar, etc. don't require an entitlement, but still trigger an OS-provided permission dialog on first use. If the user doesn't approve, access to those API's just fails. It doesn't matter if the app didn't trigger those API's during the review process. The first time it does at runtime, the dialog pops up. Granted less savvy users might just hit "Approve," but if you read dialogs before mashing your thumb on the screen, a JSPatch app can't just run off with your data.

      As for the suggestion in the article that the app would modify system settings etc? Pure FUD. In order to expose that functionality to JavaScript, the JSPatch library itself would have to contain references to those symbols. Any binary that refs non-public API symbols is rejected. Whether the code actually calls them or not is immaterial*. If JSPatch did anything polymorphic to conceal the presence of those symbols, I'm pretty confident the thing would get blacklisted double quick.

      *Source: I had an app rejected once because one of my own function names happened to match a private API. Had to rename my function to get it approved.

  12. Re: Converted into Obj-C? by tricorn · · Score: 1

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

  13. Perhaps the point was too few Mac users by tepples · · Score: 1

    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.

  14. Re: Weird by macs4all · · 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 was slow to learn that the world wasn't one big, happy, computing family, and they (well, mostly their users) suffered for decades because of it.

    But by the time Android came around (especially considering it is the idiot-bastard-son of Linux, which is the idiot-bastard-knockoff of Unix) there was simply NO excuse to not have a more "hardened" approach to software distribution, like iOS does.

    Call it a Walled Garden or whatever, the proof is in the pudding...