Slashdot Mirror

← Back to Stories (view on slashdot.org)

How a Mobile App Firm Found the XcodeGhost In the Machine (computerworld.com)

Posted by timothy on from the gut-feeling-on-top-of-a-hunch dept.

SpacemanukBEJY.53u writes: A Denver-based mobile app development company, Possible Mobile, had a tough time figuring out why Apple recently rejected its app from the App Store. After a lot of head scratching, it eventually found the XcodeGhost malware hidden in an unlikely place — a third-party framework that it had wrapped into its own app. Their experience shows that the efforts of malware writers can have far-ranging effects on the mobile app component supply chain.

6 of 69 comments (clear)

  1. WHY? by H3lldr0p · · Score: 3, Insightful

    I don't understand why, as a commercial, professional developer you didn't take the time to find or demand a copy of the code from a third party plug-in. And if you couldn't do that, why you'd still go and use it. That seems like a huge amount of built-in trouble.

    Can it be cheaper to not do your homework? Certainly! But look at what it costs you. You now have an app that's getting rejected by the publisher. You've now gone and tarnished your brand and reputation. And you've likely opened up your users to all kinds of possible trouble, not to mention any future ramifications of the if/when their data is stolen.

    Why not just do the homework and be safe from the start?

    1. Re:WHY? by dgatwood · · Score: 4, Insightful

      Ads. Unfortunately, most of the advertising frameworks out there are closed source. And buggy. I've spent way more time than I'd like working around bugs in closed source frameworks by hot-patching system libraries to prevent them from doing things that cause problems (leaks, crashes, etc.). But if you want to show mobile ads from those companies and get paid, your only option is to use their frameworks, and to deal with their closed-sourcedness.

      Annoyingly, neither the Slashdot story nor the linked story nor the blog post linked from there contains the name of the actual framework. So someone who should have known better, whose reputation should get tarnished, doesn't get his/her/their reputation tarnished, all the while exposing potentially a quarter million developers to the risk of getting their reputations unfairly tarnished by this poorly created framework. That's seriously uncool.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

  2. Re:And that's by _merlin · · Score: 4, Insightful

    Using a different build tool won't protect you from an infected 3rd-party library.

  3. Only a fool would add libraries without knowing wh by Dr_Marvin_Monroe · · Score: 4, Insightful

    From the supposed CTO...."Trying to figure out what is in a binary is what security researchers do, not app developers, Graves said. After scratching their heads, they guessed that the problem was probably in a third-party framework.". Sorry, you're wrong, that's exactly what app developers are supposed to do.

  4. Apple no longer looks as paranoid as it did. by tlambert · · Score: 3, Insightful

    Apple no longer looks as paranoid as it did.

    Previously, they did not permit the use of third party libraries in your application; everything had to be built or sourced by you, because there's no intermediate library signing and vetting process that Apple can do on your behalf. They relaxed this when developers screamed like a stuck pig.

    They are looking a lot less paranoid in their prior restriction, now.

    I'm happy that Apple was clever enough to reject the App, and somewhat disappointed that the developers had such a hard time reading the rejection notice that they were left scratching their heads.

  5. What third party library by EmperorOfCanada · · Score: 3, Insightful

    Name some names. Telling me that some random third party library out there has this is a huge pile of steaming useless information. Name some names.