Slashdot Mirror
How a Mobile App Firm Found the XcodeGhost In the Machine (computerworld.com)
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.
Old man yells at iCloud. (And man, I'm old. That's just a joke that applies in this case.)
"Old man yells at systemd"
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?
Using a different build tool won't protect you from an infected 3rd-party library.
How is that third-party library an unlikely place to contain malware?
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 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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
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.
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/iPad with Code::Blocks anyway? Don't you need to use Xcode in some form for the signing process to work? I could be wrong, I've never actually developed an iApp, but I suspect AC hasn't either.)
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 demonstrates that. Apple caught the problem before allowing the app in their store, which successfully prevented the distribution of the malware in this case. The developer in turn figured out which of his vendors was at fault.
Is that a lot of effort doing something that wouldn't be necessary in an ideal world? Sure. Is it annoying? Absolutely. Is it beyond the ability of a skilled professional developer to deal with practically? No.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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...
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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....
Old man overdoes his medication, yells at clouds.
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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?
In the free world the media isn't government run; the government is media run.
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 and it's very hard to inspect a binary, generally in those cases it is fully on the company that sends you the binary to ensure it is secure.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
seen the source code of or written yourself.
The words are in English, I'll grant you that...
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.
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.
I am not sure if my typo is ironic or oddly appropriate. You're still a know-nothing.
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 the option to open the source of code that I write, I almost invariably do so. So don't lecture me about opening up my source code. You're preaching to the choir here. Besides, in the case of the software I'm working on at the moment, the software would actually not serve the public's interests nearly as well if it were open source for reasons that I won't go into in a public forum (and no, the reasons don't involve DRM or advertising).
Second, there's a huge difference between source code for an app that end users are supposed to use and a framework that developers are supposed to incorporate into their own products. Out of the dozens of apps that I use, I can count the number that can make or break my ability to get an app out the door on one hand. Basically, Xcode and the tools that ship as part of it. Everything else has drop-in replacements. Photoshop acting up? Switch to Pixelmator. Buggy text editor? Use another one. And so on. So the fact that those tools are closed source is of only moderate concern, with the exception of Xcode, which I very much wish were Open Source, both because it is such a critical part of the process and because it can be pretty cranky at times.
By contrast, a closed framework is another animal entirely, because it puts the very success of software that I'm writing entirely in the hands of another programmer. They rank right up there with Xcode in terms of their ability to cause harm, because they are part of your app. If something happens in six months, and one of those ad networks starts delivering ads that cause a particular version of an ad framework to crash constantly, you may or may not be able to adequately kill that app framework in a way that gets your app back to a functional state without shipping a new version of the app and waiting up to two weeks for Apple to review. And even then, the only thing you can do is to disable one of your sources of revenue.
By contrast, with an open source framework, if it starts crashing, you can report the problem upstream and simultaneously start figuring out why it is happening, potentially fixing the problem, or at least figuring out what edge case triggers the crash so that you can ask the ad network to temporarily suspend ads that would trigger the edge case. So this is a much, much, much better position to be in.
Check out my sci-fi/humor trilogy at PatriotsBooks.