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.
Why I use make and Code::Blocks on OSX (And Linux, And BSD... Still use VS on Windows though. Gotta love me some Intellisense.)
The big problem with xcode? Gotta have an Apple account...
! x 2
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?
How is that third-party library an unlikely place to contain malware?
"We downloaded a plugin and it had malware in it" is not a story. Don't give these clowns any more attention than they've already received.
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.
Thank you for warning me about this company.
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.
This whole article is completely whacked. It couldn't be more clear that these guys have absolutely no idea what they're doing.
Xcode does not support bundling dynamic libraries with iOS applications. It's strictly prohibited by the app store because Apple's signing process only verifies the application binary, and nothing else. That means that any code you download from the internet is going to be distributed as a static library. Anything you use from that library is going to be included in your application binary, and therefore when Apple says "your application contains code that wasn't built with a legit version of Xcode", they're 100% correct.
So if your Xcode installation is verified, and your source code is clean... what else could it possibly be? I wonder how much time they billed their clients for this clusterfuck while they went on a wild goose chase trying to figure out what the hell the problem was.
Furthermore, what really gets me, is that they claim to have contacted the offending vendor and gotten a clean version of the framework. How do you know that version of the framework is clean? At the bottom of the same fucking article, they say that they've already heard of a new version of XcodeGhost that employs obfuscation so you can't grep around in the binary file for known strings. How do they know their vendor didn't give them a version of the framework with this new and improved version of XcodeGhost?
I like how they don't even mention what the framework is to begin with. I'm guessing it's some super shady tracking/analytics/advertising package. But don't worry, because they'd never ship an application without such important core functionality! What a load of rubbish. I'll make note to avoid these guys in the future if I ever need to outsource any development work.
At each major update, Microsoft launches its latest Malware Removal Tool which I believe is the longest running part of the update process but at least they are checking their OS for malware infected components. Why can't iOS App store has something similar? And please retrograde this shit. There is no way I'm updating my iOS7 iPad2 to iOS9 and brick it. Now that would be true definition of malware: "No need for malware guys, just install our latest iOS update on a device which we said it will defo run. And then your only option when it's broken is to come to us to buy a new model or pay £144 out-of-warranty repairs!"
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.
Every time Apple uses the word "framework", Jesus kills a library. Think of the libraries!
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.
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.
Then perhaps you would like to explain the purpose of a security researcher/analyst position otherwise? It's not like the parent just pulled that job out of their ass for this argument, and based on the amount of shitty code being banged these days, we could use the extra scrutiny, which feeds the irony of this very topic.
I promised to never post here again, but you seem legit. Your argument is the same as all those BS psych/medical researchers who just "need to do it to survive", meaning phack and not replicate each other and have shitty vague theories. This has gone to an extent that it is destroying every pillar of civilization that was built by those before. Guess what, being a pawn in destroying what is great is not a worthwhile life. Go do something better.
Where does it stop? When we've checked every framework/library source and compiled it ourself? Or should we also write our own compiler in machine language and then compile our open source operating system. Perhaps even that is not enough, think of the closed source firmware we're dealing with every day..
I bet if that's the entry level the app stores will be pretty empty.
See subject: Dependencies only on native system level API from libs/dlls already present in the OS. "Web apps" stuff? Too many "moving parts" - sorry webboys, but this is part of the price you're paying for "convenience & ease" which this article evidences.
So what else can do what these things do? DCOM/Corba!
However - to master them is more difficult (by far) but webservices type design made it easy for just about anyone to join the party (which I suppose, has its merits) but this article's topic's the price paid.
Yes DCOM uses rpc. Rpc has some 'holes' too but then again, how many of those do you see in comparison to 'web app' flaws popping up for years now? Not that many.
Plus, you can stop them by following 'best practices' shown here @ Microsoft https://technet.microsoft.com/...
This also goes for using unproven libs/dlls in "standalone" programs. I rarely did, but sometimes I had to (Crystal Reports in what I did for a living in MIS/IS/IT business development - Saves time & proven - company who produced it kept up on it, had a fortune to build & LIABILITY).
However:
What if development, support, or patching them stops/company goes under etc.?
You're up the shit creek minus a paddle.
E.G. -> I built this as "1 moving part" only APK Hosts File Engine 9.0++ SR-2 32/64-bit http://start64.com/index.php?o... & that's the reason why - I also have TOTAL control over its code.
One of my 'competition' doesn't (HostsMan which lacks features mine has in hardcoded favorites @ top of hosts added speed above adblocking + reliability vs. DNS security issues or exploits (many)) & they used SQLite (many browsers do also) - that's fine until they go away (they probably won't though but you never know) OR don't go 64-bit (I have no idea if they do or not to be honest - feel free to enlighten me on that front) - if those things happen to it? For HostsMan it's "out go the lights".
APK
P.S.=> Want a job done RIGHT? Build it, ground up hands-on, yourself... apk
Get on topic and enjoy your -1 moderation troll.
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.
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....
He's not that old. Sadly.
So you're a dishonest individual who pretends to hold the moral high-ground and feels that any of their points should actually be given merit when you, yourself, can't even keep a promise to yourself. If you lie to yourself then you lie to everyone else. If you're dishonest there's no reason to read the rest of your post - indeed, I stopped there.
stop spamming your stupid shit in irrelevant threads
does it work in iOS or OS X? no
your shit doesn't even work in Linux
shit spammed programs from shitposters
nobody of any note will actually recommend your application and twisting the guy at mbam's words to claim they recommend your application is bullshit and you know it
or maybe you don't you demented fucktard
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.
Can you stop me? Hell no, lol. Who cares what you think? You don't possess sufficient intellect to think much less create anything at all. I could easily port to MacOS X &/or Linux. I don't. Compared to Windows, they're not worth my time since the host file itself created on Windows using my ware runs on both of them (& it's what counts the most, the hosts file itself).
You're powerless - accept it. Especially vs. me!
APK
P.S.=> You WISH people from the likes of Malwarebytes would host AND RECOMMEND your wares as they do mine here -> http://hosts-file.net/?s=Downl... AND YOU WISH YOU WERE ME, you jealous little dolt - only problem is, you lack the skills + intestinal fortitude to do so (& you KNOW it) - LMAO... apk
How do you figure he's twisting the malwarebytes guys words? It's right here on his site in black and white near the top http://hosts-file.net/?s=Downl...
Hohohohoho, jealous of apk are we? Yes. It's your fault for being a ne'er do well as he names your kind loser. I just call you what you are. A loser.
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
... news at 11pm.
but seriously, if they weren't such cheap-ass sleazebags, they wouldn't be unknowingly pushing viruses on us.
You have to take full responsibility for whatever havoc is caused by your using someone else's software.
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.
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.