I guess you are unaware of CyanogenMod, AOSP and xda devs.
I am aware of them just fine; but if I have to essentially "Jailbreak" my Android to fix it, then that's hardly a viable solution for most people that have any phone, including most people that own most Android phones.
It's bad style, and obscures your point. With which I wholeheartedly agree, as it happens.
I wonder, could apple even store the source code, for subsequent examination should your app ever prove malicious? It's a very interesting idea, and I'm going to bet that Apple are considering that option seriously.
Sorry, showing my age. When I first started commenting on the interwebs, ther simply wasn't styled text. So, it wasn't uncommon for people to show emphasis with various other methods, including capitalizing. Yes, I know how to use HTML tags in/. Comments, but I get sooooo tired of entering them by hand...
Thanks for the support! I'm sure that Apple is worried about Developer Backlash at the suggestion that they surrender their Source to Apple for Compilation. But I do think it is an intriguing idea.
To an increasing number, it's a computer than happens to be able to make phone calls.
I understand that; but for most people, it's still primarily a phone. And for those people, it it a device that carries around a disproportionate amount of sensitive, personal information. So, I really don't think that security measures such as strict sandboxing are such a bad idea. There are more than enough file-manipulation Apps for iOS that no one should have trouble getting files on/off of an iOS device. In fact, I just discovered the other day that there is a Lightning to USB cable (Amazon even has a third party one for $3), which file-manipulation Apps like GoodReader can use to quickly transfer files onto/off of, any iOS device. And if your device is pre-lightning, you can use WiFi in several different ways with GoodReader or several other Apps to accomplish the same thing.
Oh, and I didn't know until the other day that the same situation exists in Android; that is, you need a File Manipulation APP to transfer files on/off of an Android device, just like iOS. The only difference is that you can muck about directly in the Filesystem, which, guess what? Most non-geeks really don't understand so well.
Who said anything about a conspiracy? I was just pointing out that it was interesting that, as malware is being discovered in the App Store, Apple is also removing the only detection method available to end users; I recognize that iOS9 was released in advance of this discovery and that the two are unrelated, but that doesn't make it any less interesting, does it?
Actually, it makes it TOTALLY uninteresting. Do you have ANY idea how much time likely elapsed between the "Feature Freeze" for iOS 9 happened BEFORE the Release Date? Jeezus.
For many years now, Apple has been hiding features and providing no immediate clues or help to the non-technical user.
They have been "hiding" features in the same way EVERY WIMP-based GUI has been "hiding" them: By placing certain less-used features on a Contextual and/or Sub-Menu. Could you do better?
How much Documentation comes with Windows?
How much Documentation does any of the MULTIPLE User Interfaces that an unsuspecting Linux User could encounter come with?
How would have THOSE UIs have exposed that somewhat dangerous and seldom-used command in a more reasonable manner; especially given that not EVERYTHING can be on the main menu-set? Iin fact, segregating less-used and/or somewhat dangerous actually IMPROVES usability (a point that is likely discussed in Apple's Human interface Guidelines).
You would have an argument if the command was available only through a Keyboard command, ala Emacs; but one of the great advantages of a GUI is that it is "DISCOVERABLE".
And so, I utterly reject your entire premise that Apple is "hiding" features, and especially not features that exist on a Menu, whether on the Menu Bar, or via a Right-Click.
Frankly, I think there is a Vas Deferens between THIS [techcrunch.com] and THIS [pcworld.com].
There is also a vast difference between the availability of tools to properly scan for and detect malware on Android and tools to do the same on iOS; without filesystem access, they simply do not and can not exist on iOS. That might explain it, dontcha think?
Oh, and BTW, XCodeGhost DOESN'T seem to affect the U.S. App Store, only China.
That's not entirely correct. About 90% of affected apps are chinese-only, but there are a number of affected apps in the US and global app stores. Further, while Lookout and other solutions can actually scan apps for malicious content on Android, due to sandboxing and lack of filesystem access, these solutions can only scan for app names and versions known to be infected on iOS; and that capability has even been removed from iOS 9. Interesting, no?
The Vas Deferens thing is a puerile joke I have used since I was a teenager, sorry.
I couldn't find any references to infected Apps in the U.S. Store, hence the comment.
Apple is in the best position to scan Apps on their own servers, anyway; so who cares about what anyone else can do? Lack of direct access to the Filesystem in iOS has significantly decreased the attack surface for malware, and has no doubt made the platform safer for everyone. It's a PHONE, get over it!
and WHY does EVERYTHING with Apple HAVE to be some big, dark CONSPIRACY?
It is funny, how people believe that Apple somehow protects them from malware. In reality, all the testing done in their appstore concentrates on verifying that apps do not have a mechanism for payments that bypass Apple. Anything is ok as long as Apple gets their cut.
yawn. This is vaguely interesting in the sense it's novel for using a ken Thompson compiler attack. But it's not an apple problem but a cheapskate developer problem . Morons saved themselves $99 dollars and use unsigned non apple compilers. Dumbasses. Apple just figured out there's dumbasses submitting code. Should be easy to detect non official compilers in the future I would think.
They didn't save themselves $99 (631 Yuan). XCode is FREE; the Developer License costs money.
Slow download and installation using the official channels does not even begin to describe it. I did some work in Xcode this spring. Two and a half hours it took to install the bloody thing even with a quick and stable connection.
Two days later I had to install a new update to be able to continue my work. Thankfully that only took slightly more than an hour.
In hindsight it was a good thing that I didn't grab it from an unofficial source, but man, was it ever so tempting.
I guess you've never installed Visual Studio, then. Even from a DVD it is quite a long process.
Not every bit of code is executed during every iteration of the main() loop, nor even every time an application runs
But that is IRRELEVANT to a code-review. It is whether a particular API Call EXISTS; NOT whether it is sitting inside a CASE or IF Statement that appears to be never reached. Even an Object Code (as opposed to Source Code) Review can spot API calls a MILE away. You can only Obsfucate SO much. It's when an App has a "legitimate" purpose for making that API Call that things get dicey. But when a Hello Kitty Game App digs into your Contacts, or your Emails, then a phone call to the Developer to see the Source is probably in order before Approval. As far as XCode goes, since Apple controls that Toolchain, it SHOULD be possible to have XCode "Police" Itself.
Or possibly, perhaps Apple changes the Submittal Process such that you (The Submitter) send Apple the XCode PROJECT FILES, and APPLE does the Final Compilation for the version that appears in the App Store. Big Vendors, such as Microsoft, Adobe, AutoDesk (and VERY few others) would be exempt from this rule; but for all the smaller Devs, THEY would have to have their Source COMPILED BY APPLE, on their "blessed" Copy of XCode. THAT, along with Source Code Review for Apps requiring certain types of API Calls, MIGHT actually come close enough to a perfect solution to be worth the extra trouble.
The very first thing Apple should do is admit that it is, in fact, possible for malware to get past their screening process.
This meme needs to FINALLY be taken out back and SHOT: As I said elsewhere in this thread; I don't think that APPLE has ever said that. Instead, it seems to be almost universally Fandroids that SAY that Apple (or their Users) have said that.
Please correct me if I'm wrong, and you can find ANY evidence that APPLE ITSELF has EVER said that their App Store Approval Process GUARANTEES no Malware.
Which API calls would those be? Any that communicate to the outside world? There goes 99% of apps getting bumped to the "higher" review. Not a tenable solution.
I'm surely not implying that, since no solution is perfect, no solution should be implemented. I'm simply pointing out that, since no solution is perfect, no perfect level of security should be implied (as has been up until this point), while pointing out that the seemingly obvious solutions are not only imperfect, but so impractical as to be unimplementable. If you manage to come up with a practical solution, great, let's hear it; the one you provided above does not qualify, for the reasons stated.
Show me where APPLE has ever implied that their security is perfect?
Pretty much, it is a meme by Fandroids, NOT Apple Users, derisively put into the mouths of the latter by the former.
This is not a dev toolchain issue. The attack avenue was the dev toolchain, but the code ended up in the binary which ended up in the App Store. you know, just like the code the app author actually wrote.
To clarify, it ended up the same place it would have ended up had the app author written it themselves. In other words, malware made it past Apple's screening process.
To further clarify, there is nothing special about how the malware was compiled into the binary that helped it pass Apple's screening process; only that it lay dormant until after the screening was complete.
Actually, I just GUESSED that code MIGHT bypass the Approval Process IF it lay dormant for a period.
But I do agree that this isn't strictly a Dev. Toolchain issue. I stand corrected on that point.
The salient question is "How does Apple change their Approval Process such that this cannot happen again?" Is that even possible? And if it isn't 100% possible, should Apple even try?
That would only prevent developers from unknowingly submitting malware to the app store. It would to nothing for purposeful malware that simply remained dormant until some time had passed. The only solution for that is to increase the amount of testing/screening time allotted to each app. A month ought to do it.
Until malware authors start leaving their code dormant for 2. then 3, 6, 12. See where this is going?
Of course, Apple would never increase the screening time to 1 month, let alone 2, 3, 6, or 12. They'd have approximately 0 developers writing for their platform if they did. So no, there is no solution; not even one involving a cat-and-mouse game with dormancy and screening durations.
The closest they could get would be to do a symbol dump of the submitted binary, identify all functional code, and require that directions for activating every bit of functional code be submitted along with the app. If a routine is found that can't be activated by following those instructions, reject the app.
Here's why that won't work:
- It makes it difficult or impossible to test applications which may call certain routines based on random outcomes (e.g. many games)
- It makes it difficult or impossible to test applications which may call certain routines based on user actions requiring much practice and skill (experience) withe the application (e.g. many games)
- It makes it impossible to test, in a reasonable timeframe, applications which call certain routines only after a set amount of time has passed
- It makes it difficult to use 3rd-party libraries, as one would have to ensure that they remove any unused routines from those libraries; this means not just stripping out any their application does not use, but also leaving in any which may be called by those their application does use. It's not always clear when some library might make internal calls to its own routines, nor always how to trigger them, which would make providing the required documentation neigh impossible, even if one were able to properly cull the code
- Even ignoring all of the above, there is nothing stopping a malware author from wrapping their malicious code in an if() statement inside a routine or function that is documented and will be tested by Apple, such that the code will lay dormant until a certain condition is met, even as the routine is otherwise executed during testing.
That is to say, as you already pointed out (while paradoxically still insisting that this should be able to be fixed):
ANY code can be obsfucated
And, more to the point, the code itself needn't be obfuscated; Apple doesn't see the code, they review the binary.
So, since no system is foolproof, we do nothing, right?
A few years ago, it DID take longer for an App to get Approved. Developers whined. Users whined. Apple Management probably whined. So they (somehow) dramatically shortened the Approval Process. Is this the result? Don't think so; but I don't really know. Do you?
Using the iOS Approval Process as an example, since API calls can easily be spotted, perhaps Apps-Under-Review that make certain iOS API Calls get kicked to a higher-tier of Review, where the Submitter HAS to hand-over their SOURCE under NDA (or something similar), and more than one Apple Developer has to manually review it, and has the right to have the Submitter explain any questionable code.
Not perfect; but perhaps better at spotting questionable code, no matter the cause.
There is no solution, but I look forward to seeing what functionality my iPad and my wife's iPhone lose as a result of whatever they propose as a "solution" in the next iOS update.
What the hell was that snarky-ass comment about?
Why would you surmise that it would affect iOS, per se? This is a Dev. Toolchain issue, and that is only OS X.
Can't ANYONE have at least a SEMI-erudite discussion around here? Or has this site just devolved into a free-for-all orgiastic pyre of hate?
Not the guy you were replying to, but I'll answer #5 anyway. It means any developer can slip malware past an Apple App Store review by making it wait a month or so before activating.
That was a guess on my part; but ANY code can be obsfucated.
The only question is, regardless of Platform, Walled Garden, etc, is there any reasonable way that this can be eliminated from possibility, without hamstringing App Developers to the point that all they CAN write is "Fart" Apps?
Does, for example, XCode have to swell to twice its size (and half the speed) by having nearly as much "self-checking" code as actual functional code? Does , for example, XCode have to be "grey-listed" such that it WON'T run if it has been modified? Or what?
Yes, it was. The counterfeit XCode the affected developers are using is dropping additional code into their projects. Think about that, seriously. That means the code is in their app (even if they can't see it). Again, think about that. Do you see how this indicates that, perhaps, a developer might be able to slip their own malware code into an app? This is only the first *detected* instance of this, because fewer people have been looking. It's probably safe to hold your breath until the next one.
I guarantee the implications of this are NOT lost on Apple. I would be VERY surprised if this HASN'T caused a major shitstorm in the Development corridors at Apple, and I am sure that they are working on a permanent solution to this even as I type.
And also, this is the first known breach affecting more than one application since the iOS App Store opened in 2008. Who KNOWS if this has been going on in Android?
Would Android malware even need it, when every dubious app demands all possible permissions before it will install?
Apple seems to ignore security and will bight them trying to get into enterprise if they cannot do better then this. No excuse to get this deep into IOS. Heads should role on this at Apple for sure.
1. Do you think that, by your own measure, that Android is any more suitable for Enterprise?
2. How can Apple control someone downloading/installing their Dev Tools from another location and then defeating the measures on their Dev. Macs to keep them from running unsigned code?
3. Apple provides a FREE source of SIGNED XCode in an attempt to thwart this sort of attack on their Dev. tools.
4. If Apple made it so that XCode could ONLY be installed as a "Signed" App, then how many DECADES before the Slashtards would STOP accusing them of "Vendor Lock-In" and "DRMed Toolchain", et FUCKING Cetera?
5. As long as the "poisoned" App is smart enough to WAIT a bit before firing off its attack on the User (thus not exposing its bad behavior during the Approval process), it is quite possible that such an attack could avoid detection by all but the most painstaking (and long) MANUAL code-review. Meanwhile, the Dev. world starts whining about how long the Approval Process takes, and Developers start fleeing from iOS...
They probably already had Gatekeeper disabled. I know I had to do this simply because of the number of tools I use as a software developer that wouldn't run otherwise. Gatekeeper's pretty good if you only play Farmville or don't do anything beyond Safari, although I wonder why you'd have a high end computer for that rather than a generic Windows system or some other portable device.
Android doesn't trade on it's walled-garden security.
That's because it CAN'T.
And this was done by fairly sophisticated means, ya gotta admit.
And also, this is the first known breach affecting more than one application since the iOS App Store opened in 2008. Who KNOWS if this has been going on in Android?
Slashdot Mirror
I guess you are unaware of CyanogenMod, AOSP and xda devs.
I am aware of them just fine; but if I have to essentially "Jailbreak" my Android to fix it, then that's hardly a viable solution for most people that have any phone, including most people that own most Android phones.
I think you should, in general, avoid capitals.
It's bad style, and obscures your point. With which I wholeheartedly agree, as it happens.
I wonder, could apple even store the source code, for subsequent examination should your app ever prove malicious? It's a very interesting idea, and I'm going to bet that Apple are considering that option seriously.
Sorry, showing my age. When I first started commenting on the interwebs, ther simply wasn't styled text. So, it wasn't uncommon for people to show emphasis with various other methods, including capitalizing. Yes, I know how to use HTML tags in /. Comments, but I get sooooo tired of entering them by hand...
Thanks for the support! I'm sure that Apple is worried about Developer Backlash at the suggestion that they surrender their Source to Apple for Compilation. But I do think it is an intriguing idea.
To an increasing number, it's a computer than happens to be able to make phone calls.
I understand that; but for most people, it's still primarily a phone. And for those people, it it a device that carries around a disproportionate amount of sensitive, personal information. So, I really don't think that security measures such as strict sandboxing are such a bad idea. There are more than enough file-manipulation Apps for iOS that no one should have trouble getting files on/off of an iOS device. In fact, I just discovered the other day that there is a Lightning to USB cable (Amazon even has a third party one for $3), which file-manipulation Apps like GoodReader can use to quickly transfer files onto/off of, any iOS device. And if your device is pre-lightning, you can use WiFi in several different ways with GoodReader or several other Apps to accomplish the same thing.
Oh, and I didn't know until the other day that the same situation exists in Android; that is, you need a File Manipulation APP to transfer files on/off of an Android device, just like iOS. The only difference is that you can muck about directly in the Filesystem, which, guess what? Most non-geeks really don't understand so well.
Who said anything about a conspiracy? I was just pointing out that it was interesting that, as malware is being discovered in the App Store, Apple is also removing the only detection method available to end users; I recognize that iOS9 was released in advance of this discovery and that the two are unrelated, but that doesn't make it any less interesting, does it?
Actually, it makes it TOTALLY uninteresting. Do you have ANY idea how much time likely elapsed between the "Feature Freeze" for iOS 9 happened BEFORE the Release Date? Jeezus.
For many years now, Apple has been hiding features and providing no immediate clues or help to the non-technical user.
They have been "hiding" features in the same way EVERY WIMP-based GUI has been "hiding" them: By placing certain less-used features on a Contextual and/or Sub-Menu. Could you do better?
How much Documentation comes with Windows?
How much Documentation does any of the MULTIPLE User Interfaces that an unsuspecting Linux User could encounter come with?
How would have THOSE UIs have exposed that somewhat dangerous and seldom-used command in a more reasonable manner; especially given that not EVERYTHING can be on the main menu-set? Iin fact, segregating less-used and/or somewhat dangerous actually IMPROVES usability (a point that is likely discussed in Apple's Human interface Guidelines).
You would have an argument if the command was available only through a Keyboard command, ala Emacs; but one of the great advantages of a GUI is that it is "DISCOVERABLE".
And so, I utterly reject your entire premise that Apple is "hiding" features, and especially not features that exist on a Menu, whether on the Menu Bar, or via a Right-Click.
Frankly, I think there is a Vas Deferens between THIS [techcrunch.com] and THIS [pcworld.com].
There is also a vast difference between the availability of tools to properly scan for and detect malware on Android and tools to do the same on iOS; without filesystem access, they simply do not and can not exist on iOS. That might explain it, dontcha think?
Oh, and BTW, XCodeGhost DOESN'T seem to affect the U.S. App Store, only China.
That's not entirely correct. About 90% of affected apps are chinese-only, but there are a number of affected apps in the US and global app stores. Further, while Lookout and other solutions can actually scan apps for malicious content on Android, due to sandboxing and lack of filesystem access, these solutions can only scan for app names and versions known to be infected on iOS; and that capability has even been removed from iOS 9. Interesting, no?
The Vas Deferens thing is a puerile joke I have used since I was a teenager, sorry.
I couldn't find any references to infected Apps in the U.S. Store, hence the comment.
Apple is in the best position to scan Apps on their own servers, anyway; so who cares about what anyone else can do? Lack of direct access to the Filesystem in iOS has significantly decreased the attack surface for malware, and has no doubt made the platform safer for everyone. It's a PHONE, get over it!
and WHY does EVERYTHING with Apple HAVE to be some big, dark CONSPIRACY?
It is funny, how people believe that Apple somehow protects them from malware. In reality, all the testing done in their appstore concentrates on verifying that apps do not have a mechanism for payments that bypass Apple. Anything is ok as long as Apple gets their cut.
Citation, hater?
yawn. This is vaguely interesting in the sense it's novel for using a ken Thompson compiler attack. But it's not an apple problem but a cheapskate developer problem . Morons saved themselves $99 dollars and use unsigned non apple compilers. Dumbasses. Apple just figured out there's dumbasses submitting code. Should be easy to detect non official compilers in the future I would think.
They didn't save themselves $99 (631 Yuan). XCode is FREE; the Developer License costs money.
Slow download and installation using the official channels does not even begin to describe it. I did some work in Xcode this spring. Two and a half hours it took to install the bloody thing even with a quick and stable connection. Two days later I had to install a new update to be able to continue my work. Thankfully that only took slightly more than an hour. In hindsight it was a good thing that I didn't grab it from an unofficial source, but man, was it ever so tempting.
I guess you've never installed Visual Studio, then. Even from a DVD it is quite a long process.
it's easy to see where people get the idea that the App Store should be safe.
And, by and far, it is safe. By the same metric, so is the Play Store.
Frankly, I think there is a Vas Deferens between THIS and THIS.
Oh, and BTW, XCodeGhost DOESN'T seem to affect the U.S. App Store, only China.
Not every bit of code is executed during every iteration of the main() loop, nor even every time an application runs
But that is IRRELEVANT to a code-review. It is whether a particular API Call EXISTS; NOT whether it is sitting inside a CASE or IF Statement that appears to be never reached. Even an Object Code (as opposed to Source Code) Review can spot API calls a MILE away. You can only Obsfucate SO much. It's when an App has a "legitimate" purpose for making that API Call that things get dicey. But when a Hello Kitty Game App digs into your Contacts, or your Emails, then a phone call to the Developer to see the Source is probably in order before Approval. As far as XCode goes, since Apple controls that Toolchain, it SHOULD be possible to have XCode "Police" Itself.
Or possibly, perhaps Apple changes the Submittal Process such that you (The Submitter) send Apple the XCode PROJECT FILES, and APPLE does the Final Compilation for the version that appears in the App Store. Big Vendors, such as Microsoft, Adobe, AutoDesk (and VERY few others) would be exempt from this rule; but for all the smaller Devs, THEY would have to have their Source COMPILED BY APPLE, on their "blessed" Copy of XCode. THAT, along with Source Code Review for Apps requiring certain types of API Calls, MIGHT actually come close enough to a perfect solution to be worth the extra trouble.
The very first thing Apple should do is admit that it is, in fact, possible for malware to get past their screening process.
This meme needs to FINALLY be taken out back and SHOT: As I said elsewhere in this thread; I don't think that APPLE has ever said that. Instead, it seems to be almost universally Fandroids that SAY that Apple (or their Users) have said that.
Please correct me if I'm wrong, and you can find ANY evidence that APPLE ITSELF has EVER said that their App Store Approval Process GUARANTEES no Malware.
Apple really shouldn't try
On this, I wholeheartedly DISAGREE.
Also... f**k my HTML skills this morning. the only thing in that entire post that should be italicized is the is at the head of the italicized block.
I hate it when that happens.
Which API calls would those be? Any that communicate to the outside world? There goes 99% of apps getting bumped to the "higher" review. Not a tenable solution. I'm surely not implying that, since no solution is perfect, no solution should be implemented. I'm simply pointing out that, since no solution is perfect, no perfect level of security should be implied (as has been up until this point), while pointing out that the seemingly obvious solutions are not only imperfect, but so impractical as to be unimplementable. If you manage to come up with a practical solution, great, let's hear it; the one you provided above does not qualify, for the reasons stated.
Show me where APPLE has ever implied that their security is perfect?
Pretty much, it is a meme by Fandroids, NOT Apple Users, derisively put into the mouths of the latter by the former.
This is not a dev toolchain issue. The attack avenue was the dev toolchain, but the code ended up in the binary which ended up in the App Store. you know, just like the code the app author actually wrote. To clarify, it ended up the same place it would have ended up had the app author written it themselves. In other words, malware made it past Apple's screening process. To further clarify, there is nothing special about how the malware was compiled into the binary that helped it pass Apple's screening process; only that it lay dormant until after the screening was complete.
Actually, I just GUESSED that code MIGHT bypass the Approval Process IF it lay dormant for a period.
But I do agree that this isn't strictly a Dev. Toolchain issue. I stand corrected on that point.
The salient question is "How does Apple change their Approval Process such that this cannot happen again?" Is that even possible? And if it isn't 100% possible, should Apple even try?
No you...
This is an open source site, not a closed-source proprietary rotten fruit site. Take your drivel elsewhere. Don't need your bullshit here.
Really? That's what YOU think it is; but the Masthead says:
News for Nerds. Stuff that matters.
It does NOT say "News for Open Source". Stuff that matters TO YOU.
That would only prevent developers from unknowingly submitting malware to the app store. It would to nothing for purposeful malware that simply remained dormant until some time had passed. The only solution for that is to increase the amount of testing/screening time allotted to each app. A month ought to do it.
Until malware authors start leaving their code dormant for 2. then 3, 6, 12. See where this is going?
Of course, Apple would never increase the screening time to 1 month, let alone 2, 3, 6, or 12. They'd have approximately 0 developers writing for their platform if they did. So no, there is no solution; not even one involving a cat-and-mouse game with dormancy and screening durations.
The closest they could get would be to do a symbol dump of the submitted binary, identify all functional code, and require that directions for activating every bit of functional code be submitted along with the app. If a routine is found that can't be activated by following those instructions, reject the app.
Here's why that won't work:
- It makes it difficult or impossible to test applications which may call certain routines based on random outcomes (e.g. many games)
- It makes it difficult or impossible to test applications which may call certain routines based on user actions requiring much practice and skill (experience) withe the application (e.g. many games)
- It makes it impossible to test, in a reasonable timeframe, applications which call certain routines only after a set amount of time has passed
- It makes it difficult to use 3rd-party libraries, as one would have to ensure that they remove any unused routines from those libraries; this means not just stripping out any their application does not use, but also leaving in any which may be called by those their application does use. It's not always clear when some library might make internal calls to its own routines, nor always how to trigger them, which would make providing the required documentation neigh impossible, even if one were able to properly cull the code
- Even ignoring all of the above, there is nothing stopping a malware author from wrapping their malicious code in an if() statement inside a routine or function that is documented and will be tested by Apple, such that the code will lay dormant until a certain condition is met, even as the routine is otherwise executed during testing.
That is to say, as you already pointed out (while paradoxically still insisting that this should be able to be fixed):
ANY code can be obsfucated
And, more to the point, the code itself needn't be obfuscated; Apple doesn't see the code, they review the binary.
So, since no system is foolproof, we do nothing, right?
A few years ago, it DID take longer for an App to get Approved. Developers whined. Users whined. Apple Management probably whined. So they (somehow) dramatically shortened the Approval Process. Is this the result? Don't think so; but I don't really know. Do you?
Using the iOS Approval Process as an example, since API calls can easily be spotted, perhaps Apps-Under-Review that make certain iOS API Calls get kicked to a higher-tier of Review, where the Submitter HAS to hand-over their SOURCE under NDA (or something similar), and more than one Apple Developer has to manually review it, and has the right to have the Submitter explain any questionable code.
Not perfect; but perhaps better at spotting questionable code, no matter the cause.
There is no solution, but I look forward to seeing what functionality my iPad and my wife's iPhone lose as a result of whatever they propose as a "solution" in the next iOS update.
What the hell was that snarky-ass comment about?
Why would you surmise that it would affect iOS, per se? This is a Dev. Toolchain issue, and that is only OS X.
Can't ANYONE have at least a SEMI-erudite discussion around here? Or has this site just devolved into a free-for-all orgiastic pyre of hate?
Way to go, Sherlock. You've discovered an issue with an outdated version of Android.
Too bad there are plenty of Android Victims, er, Users, that apparently are still running that version, thanks to Android's lack of updating.
Did you notice that there were comments as recently as May, 2015? So how "non-relevant" can it be?
Not the guy you were replying to, but I'll answer #5 anyway. It means any developer can slip malware past an Apple App Store review by making it wait a month or so before activating.
That was a guess on my part; but ANY code can be obsfucated.
The only question is, regardless of Platform, Walled Garden, etc, is there any reasonable way that this can be eliminated from possibility, without hamstringing App Developers to the point that all they CAN write is "Fart" Apps?
Does, for example, XCode have to swell to twice its size (and half the speed) by having nearly as much "self-checking" code as actual functional code? Does , for example, XCode have to be "grey-listed" such that it WON'T run if it has been modified? Or what?
Yes, it was. The counterfeit XCode the affected developers are using is dropping additional code into their projects. Think about that, seriously. That means the code is in their app (even if they can't see it). Again, think about that. Do you see how this indicates that, perhaps, a developer might be able to slip their own malware code into an app? This is only the first *detected* instance of this, because fewer people have been looking. It's probably safe to hold your breath until the next one.
I guarantee the implications of this are NOT lost on Apple. I would be VERY surprised if this HASN'T caused a major shitstorm in the Development corridors at Apple, and I am sure that they are working on a permanent solution to this even as I type.
And also, this is the first known breach affecting more than one application since the iOS App Store opened in 2008. Who KNOWS if this has been going on in Android?
Would Android malware even need it, when every dubious app demands all possible permissions before it will install?
Good point!
Apple seems to ignore security and will bight them trying to get into enterprise if they cannot do better then this. No excuse to get this deep into IOS. Heads should role on this at Apple for sure.
1. Do you think that, by your own measure, that Android is any more suitable for Enterprise?
2. How can Apple control someone downloading/installing their Dev Tools from another location and then defeating the measures on their Dev. Macs to keep them from running unsigned code?
3. Apple provides a FREE source of SIGNED XCode in an attempt to thwart this sort of attack on their Dev. tools.
4. If Apple made it so that XCode could ONLY be installed as a "Signed" App, then how many DECADES before the Slashtards would STOP accusing them of "Vendor Lock-In" and "DRMed Toolchain", et FUCKING Cetera?
5. As long as the "poisoned" App is smart enough to WAIT a bit before firing off its attack on the User (thus not exposing its bad behavior during the Approval process), it is quite possible that such an attack could avoid detection by all but the most painstaking (and long) MANUAL code-review. Meanwhile, the Dev. world starts whining about how long the Approval Process takes, and Developers start fleeing from iOS...
So, what are your answers to THOSE points?
They probably already had Gatekeeper disabled. I know I had to do this simply because of the number of tools I use as a software developer that wouldn't run otherwise. Gatekeeper's pretty good if you only play Farmville or don't do anything beyond Safari, although I wonder why you'd have a high end computer for that rather than a generic Windows system or some other portable device.
1. You can reduce GateKeeper to the "Warn" level
2. You can always Right-Click and Force a Run
3. It only happens once per App. Deal with it.
Apples stuff can not get virus/malware/trojans.
Any platform can get Trojans.
And when the Development Tools ARE the vector, it's pretty much like having physical access.
Can you prove that a similar thing hasn't been done to common Android Dev. Tools?
Yesterday it was broken iPhone VPN, today it's hacked apps via xcode. Blah blah blah. Real techs use Android.
Ahem. As was pointed out yesterday on Slashdot to a Fandroid who made pretty much the same claim...
Still better than that malware Android
Android doesn't trade on it's walled-garden security.
That's because it CAN'T.
And this was done by fairly sophisticated means, ya gotta admit.
And also, this is the first known breach affecting more than one application since the iOS App Store opened in 2008. Who KNOWS if this has been going on in Android?