How a Mobile App Firm Found the XcodeGhost In the Machine (computerworld.com) 69
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.
Re:And that's (Score:5, Insightful)
Using a different build tool won't protect you from an infected 3rd-party library.
Re: (Score:3)
You're completely missing the point of the article: it doesn't matter if your development environment is clean if a library you use was built in a trojanised environment. Whichever IDE or build tool you use the same applies. It wouldn't have mattered whether the app developer used clean Xcode, clean Code::Blocks, or whatever, the malware got into their app by way of a third-party library built with a bad copy of Xcode. The moral is, be careful who you trust.?
(Also, can you actually develop for iPhone/iPa
Re: (Score:3)
XCode is only an IDE. Under the hood it uses ordinary command line tools, so signing by using a different IDE is only a matter of calling the signing tool with the right parameters.
Re: (Score:2)
You must not have read the article-- it was a third party binary library compiled on a trojaned Xcode.
Curse you for making me read the actual article... "Using a command line tool, grep, to search the library for known URLs..." Wow! Rocket Science! Makes me want to never purchase an app from the company that paid for the advertisement...
Re: (Score:3)
Old man yells at iCloud. (And man, I'm old. That's just a joke that applies in this case.)
Re: (Score:2)
WHY? (Score:4, 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?
Re:WHY? (Score:5, 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.
Re: (Score:1)
If you weren't so completely ignorant of the fact that you're completely ignorant, you might be a passable human being. As it is, the cows are better company.
Re: (Score:1)
seen the source code of or written yourself.
The words are in English, I'll grant you that...
Unlikely place? (Score:1)
How is that third-party library an unlikely place to contain malware?
Non story (Score:1)
Only a fool would add libraries without knowing wh (Score:5, 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.
Re:Only a fool would add libraries without knowing (Score:5, Interesting)
App developers have only limited time to devote to such things. Sure, when we integrate a brand new framework, we dig in a bit to see if there's anything suspicious, but apps have to routinely update these third-party frameworks to the latest versions to fix bugs and crashes. It just isn't practical for developers to give that level of scrutiny to every minor update. If we did, we'd never have time to do anything but update third-party frameworks.
This is, BTW, why framework developers should not be in the business of supplying precompiled binaries. The framework devs are causing added security risk for app developers, and also exposing themselves to significant liability if they make a mistake like this. And when Apple has to make a compiler change for something like app slicing or whatever, closed-source frameworks cause huge overhead for developers that wouldn't exist if all the code were being compiled by the actual developer. And when there are bugs (which there always are), closed-source frameworks make working around them a big headache. So they really are a nightmare for us.
And trust me when I say that there's nothing in your ad or analytics framework that is so amazing that it qualifies as a competitive advantage. If you think otherwise, you're only kidding yourselves. Just open the source already.
But I digress.
Re: (Score:1)
So where's the link to your app's source? Oh, you mean that your rant only applies to source you want to have, but not source you write? If you're releasing binary-only apps, don't complain about binary-only frameworks. You are certainly free to only integrate those that provide source. No one is stopping you, nor is anyone forcing you to use any given framework.
Re: (Score:2)
First, I write a fair amount of open source software. I've released source code for tools that parse source code and emit documentation, libraries for parsing and writing OMF files (Bento containers), code for parsing BIAS Deck project files (for moving content off of a dead audio software platform), various cool shell scripts (by definition, open source, I suppose), minor bug fixes to libxml2's HTML parser.... And I used to be involved in shipping a couple of Linux ports back in the day. When I have th
Re: (Score:2)
Well what is prudent and necessary to do is a matter of what threats exist in practice. If *all* those concerns you listed proved to be popular vectors for malware you'd have to check all those things, or admit to customers your software is untrustworthy.
Fortunately there are intermediate levels of paranoia between trusting everything blindly and building everything up from machine language. There are choices you can make about who to trust and what steps to take to verify that trust. This story demonstra
Re: Only a fool would add libraries without knowin (Score:2)
Now your just making excuses for sloppy work. As a mobile app developer myself, I check ( at least once ) any library/framework that goes into a delivery. I don't bother with the OS, as I assume Google/Apple have that covered. There, that wasn't so hard....
Re: (Score:2)
Whom on /. do you expect to believe you that?
Sorry, there is no way that you know all the sourcecode of the libraries/frameworks you use, except you only write "Hello World" programs and 'link' the required parts as sources.
Now go back into your cabinet and dream about your brave new world.
Re: (Score:2)
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.
App developers are just construction workers, they aren't engineers, they aren't scientists.
They just clip construction blocks together. Why would they have any clue whats inside the construction blocks? Why should they?
Wrong, that is what LIBRARY developer should do (Score:2)
For iOS software, most third party libraries are brought in as source, which means you are compiling them with your own Xcode - which indeed you should know if you obtained from Apple or not. That part is very much on the application developer to ensure both the code and the build chain do not have security issues.
Third party libraries that come in as binaries are a very different matter though. They are all from companies, who you pay money for the use of the library - since you cannot inspect the source
Re: (Score:1)
You make it sound exactly as if you have never done any professional iOS development. Ever.
Re: (Score:2)
I am curious what part of what I said you think does not correctly represent iOS development.
iOS development has always leaned heavily on a lot of third party code, in part because there are a lot of great choices out there.
Paid libraries are more rare but they do exist. I have been a developer of some, and a consumer of others. They have their place and are sometimes unavoidable... I don't know that a large number of apps use them but I'm pretty sure it's a significant percentage.
Re: (Score:1)
If you weren't an ignorant no-nothing, you wouldn't have to be a coward. iOS has supported dynamic frameworks since iOS 8. The current release is 9.1, and 9.2 is in beta. Also, Xcode has supported linking to pre-compiled third-party libraries since forever, so the dynamic part doesn't matter in the least.
Re: (Score:1)
I am not sure if my typo is ironic or oddly appropriate. You're still a know-nothing.
Apple no longer looks as paranoid as it did. (Score:4, 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.
Re: (Score:2)
This has never been true and the bit about developers screaming like pigs is pure fantasy.
Perhaps you're getting it muddled up with the fact that iOS didn't support dynamically linked libraries? In any case, no
Re: (Score:1)
How does shit like this get modded insightful?
Apple has allowed iOS apps to link to 3rd-party precompiled libraries since the iPhoneOS 2.0 SDK was released (that was the first public version). Even if you meant frameworks, you are incorrect.
What you couldn't do is dynamically link. That restriction was removed in iOS 8.
What third party library (Score:4, Insightful)
What this boils down to (Score:1)
Apple can't tell you which file is bad. You have to scan them yourself.
Nice heroic effort to track it down on their part; but I wonder if a general-purpose malware scanner could have saved them some time.
Re: (Score:2)
Apple can't tell you which file is bad. You have to scan them yourself.
Nice heroic effort to track it down on their part; but I wonder if a general-purpose malware scanner could have saved them some time.
I doubt its that Apple can't; its more likely that Apple doesn't want or can't be bothered.
They may even have an ulterior motive when an app developer is creating something that Apple themselves have an app developer working on; they'll just reject the app and give no reason just to block the dev so they can bring it to market themselves, or even try to discredit a dev to blow away their business.
Re: (Score:1)
They might also be conspiring to lick your dog's tail.