Number of XcodeGhost-Infected iOS Apps Rises 169
An anonymous reader writes: As the list of apps infected with the XcodeGhost malware keeps expanding, Apple, Amazon and Baidu are doing their best to purge their online properties of affected apps, malicious Xcode installers, and C&C servers used by the attackers to gather the stolen information and control the infected apps/devices. China-based jailbreaking Pangu Team claims that the number of infected app is higher than 3,400, and have offered for download a free app that apparently detects the Trojanized apps.
Detects and exploits (Score:4, Interesting)
>> free app that apparently detects the Trojanized apps
"detects and exploits" probably
Re:Detects and exploits (Score:5, Funny)
"It's an App!" - Admiral Ackbar
Re:Detects and exploits (Score:4, Funny)
Re: (Score:2)
"It's a *!" -- Admiral fapbar
Re: (Score:3)
Don't slander Pangu. They have a reputation to uphold, and they are already trusted with root on many jailbroken devices- because they have written several of the jailbreaks. All the guys that make jailbreaks happen don't want to see people fucking with jailbreakers.
Still better than that malware Android (Score:2, Funny)
Still better than that malware Android
Re: (Score:2)
Still better than that malware Android
Android doesn't trade on it's walled-garden security.
Re: (Score:2)
And this isn't about Apple's security. Remember, YOU MUST JAILBREAK for this to bite you. Much more than just jailbreak. Not only do you have to give some Chinese hacker group admin permission on your PC (which seems to be totally safe, but hey, this would normally be a red flag, right?), then you have to tell your phone that you trust what's going on. Then you have to take the jailbroken thing which provides its own repo of code, and say "nope, still not dangerous enough", then find some russian hacker
Re: (Score:2)
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?
Re: (Score:2)
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!
Re: Still better than that malware Android (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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?
Re: (Score:2)
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 pro
Re: (Score:2)
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?
Re: (Score:2)
Actually, I just GUESSED that code MIGHT bypass the Approval Process IF it lay dormant for a period.
And you guessed correctly.
The salient question has been answered. No, it is not possible. Not every bit of code is executed during every iteration of the main() loop, nor even every time an application runs; there are an infinite number of reasons a given piece of code may lie dormant during a given execution of an application, which precludes the use of dormancy as a review flag. Given that this is something that wither works 100% or works 0%, no, Apple really shouldn't try; it gives users a false sense
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Fandroids that SAY that Apple (or their Users) have said that.
As stated in the other thread where you raised this "issue", I've grown sick of my Apple fanboi friend making the claim that "this wouldn't happen on iOS" every time there's even a hint of a mention of Android malware. Hopefully this will put an end to it. And you can't really call someone sitting in front of an iPad and a Mac that are his two primary computing
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Okay, I'll byte: The safest place to download apps for your Mac is the Mac App Store. Apple reviews each app before it’s accepted by the store [apple.com]
Yes, that's about the Mac App Store. Do you want something about the App Store? No problem: We review all apps submitted to the App Store and Mac App Store to ensure they are reliable, perform as expected, and are free of offensive material [apple.com]
It seems as official as it can get, don't you think?
RT.
Re: (Score:2)
I think it's a question of scale.
With the compromised toolchain, a large number of infected apps were submitted. Depending on how the malware is hidden inside the app, tracking down all of them infected apps might be difficult. If the malware authors were smart, and I rather assume that they are, then each of the apps may be infected in subtly different ways.
With your regular malware author, a single infected app is submitted, and when discovered is removed and (presumably) the developers account suspended
Re: (Score:2)
Of course there are solutions. Have developers submit their source for Apple to build, instead of an already-built bundle. This could be through an automated process that does not expose the source to Apple or to anyone else, and would prevent trojanned toolchains of any sort.
However, it seems to me that a trojanned xcode isn't really the issue here. If the malware was hidden inside the provided application files, then what's to prevent people from doing the same kind of thing knowingly?
Re: (Score:2)
However, it seems to me that a trojanned xcode isn't really the issue here. If the malware was hidden inside the provided application files, then what's to prevent people from doing the same kind of thing knowingly?
That's precisely what I was getting at when I said:
Do you see how this indicates that, perhaps, a developer might be able to slip their own malware code into an app?
Just a couple messages up in this very thread. That is what I meant by "there is no solution". The context was there the whole time; it's not my fault you didn't care to read it.
Re: (Score:2)
The context was there the whole time; it's not my fault you didn't care to read it
Typical slashdotter rudeness. Fine. Carry on.
Re: Still better than that malware Android (Score:2)
In all seriousness, though, I really did say it just two messages earlier. Are you seriously saying it was rude of me to point that out rather than accept your "correction" as though it hadn't already been said? Might want to take a look at how you approached me before calling my reaction rude.
Re: (Score:2)
That's also ignoring that the code being injected by the affected copies of XCode is injected just ahead of compilation; why could it
Re: (Score:2, Informative)
Way to hint at bigotry. Who cares if "homosexuals" read slashdot, how does that affect you at all? FULL STOP. It doesn't.
Now tighten up your manbun.
I agree, both "ecosystems" have their flaws. there's a start difference between IOS and Android.
IOS is a walled in garden, closed source, and you have to PAY to be a developer. You have no choice as to your "app store" without jailbreaking your device. This was done to "protect" it's users with a secured, walled in, app store. Clearly this failed
Android i
Re:Still better than that malware Android (Score:5, Informative)
Not anymore. XCode 7 adds the ability to deploy to any personal device for "free".
Quoted because you need a Mac to run XCode.
But as long as you compile the code yourself (way to go - a proprietary OS enforcing open-source!), you can load the code on your phone.
In fact, there are emulators out there (like provenance, gba4ios, etc) that people are using just fine on their iOS devices. All you need to do is get the code from a tarball or git/svn/etc, open in XCode, build and deploy to your iPhone or iPad or whatever.
No, it doesn't qualify as "Free" because the built binary is limited to running on your own devices.
And the iOS sandbox was not breached - the amount of information the malware could access without alerting users was pretty limited anyhow - you could get the date, time, application ID, UUID (which because of advertising, is now different per-app) and a few other things. If the malware tried to access contacts, photos, or GPS, an alert would show up asking if the user wanted to allow or deny the action.
Of course, if said iOS device was jailbroken, then the malware could get way more information because the sandbox would be broken.
As bad as it goes, the infected apps really get less information than a typical app which wants to do in-app advertising.
Re:Still better than that malware Android (Score:4, Informative)
As bad as it goes, the infected apps really get less information than a typical app which wants to do in-app advertising.
Unless the infected app is supposed to request permissions for GPS, address book, calendar, photos access, etc etc. If snapchat were to become infected, as an example, they would have access to pretty much every piece of information you can get inside a single app except for the calendar.
Re: Still better than that malware Android (Score:3)
Android is open source - except for the large part that is Google Play Services, and Google apps, and many of the hardware drivers, and the third party apps that most OEms and carriers put on their phone.
Parts of iOS are open source (Darwin). It's a distinction without a difference.
You don't have to pay to b
Re:Still better than that malware Android (Score:4, Informative)
It matters because "IOS" is a different operating system, made by Cisco. Sure, it's clear from context which one is being talked about in this case, but that's not always true.
(On a related note, it was pretty stupid of Cisco to license the trademark.)
Re: (Score:3)
IOS [wiibrew.org] is also the name of the Wii's operating system, developed by Nintendo and BroadOn.
Re: (Score:2)
Re: (Score:2)
(On a related note, it was pretty stupid of Cisco to license the trademark.)
As much as I dislike Cisco for doing it, they were stupid all the way to the bank.
Re: (Score:2)
It will be more confusing with both Apple and Cisco making that recent deal. :O
Re: (Score:2)
Reply #1: Oh, look at me, I'm a human calculator! I'm smart, you're dumb!
Reply #2: Thinking is hard! Let's go shopping!
Reply #3: People are lazy.
Reply #4: (insert your own reply here, I'm too lazy to think of another one)
Re: (Score:3)
Also, who decided that 20% is now the "standard" tip amount? It's supposed to be 15%!
The minimum wage hasn't kept up with inflation in over twenty years. Be a sport.
Re: (Score:2)
Also, who decided that 20% is now the "standard" tip amount? It's supposed to be 15%!
The minimum wage hasn't kept up with inflation in over twenty years. Be a sport.
Restaurant prices have kept up with inflation... so a 15% tip on the restaurant bill has also kept up with inflation.
Re: (Score:2)
Restaurant prices have kept up with inflation... so a 15% tip on the restaurant bill has also kept up with inflation.
Right, but food runs hot and cold... well, no, that's water. But the point is, there's good and bad times and sometimes they have to live on sub-minimum-wage so help 'em out eh? Unless they're better dressed than you, then ok, 15%
Re: (Score:2)
Restaurant prices have kept up with inflation... so a 15% tip on the restaurant bill has also kept up with inflation.
Right, but food runs hot and cold... well, no, that's water. But the point is, there's good and bad times and sometimes they have to live on sub-minimum-wage so help 'em out eh? Unless they're better dressed than you, then ok, 15%
The "rule" in San Francisco is 2X sales tax: you don't pay tip on the tax, and it works out to exactly the right percentage to be a "relatively good tipper" on the pre-tax bill.
Re: (Score:2)
To calculate a 20% tip, move the total's decimal point one place to the left then multiply by two. Everyone should be capable of that. Calculating a 15% tip is slightly harder (requires dividing by two, then adding the original and divided value), and an 18% tip is reasonable to use a calculator for.
Also, who decided that 20% is now the "standard" tip amount? It's supposed to be 15%!
To calculate an 18% tip, move the decimal place again, and subtract that value from the 20% value you calculated.
Unless, you know, dividing by two combined with addition is easier than multiplying by two and subtraction?
P.S.: Yes, I know: New Math rather than rote memorization of up to two digit by two digit operations so that you can instantly spit out answers it takes more than a few seconds for a 20 year old to process through is "better", right? ;^)
Re: (Score:2)
I can suss out a 20% tip in my head in seconds, but I see people doing it on their smartphones. ... I'll likely get flamed for this post, because the /. readership is not what it once was.
Dangum Cleatus! He done got been able to shift yon decimal point and multiplies it by two! HooWee that there's a smart fella! I reckon the rest of us hill folk'll have to go an' un-dawn our socks to calculate that particular quandary. 'Dis here sophistimicated gentleman should be our next precedent! AC for the White House!
Re: (Score:2, Interesting)
You know, that there exists apps to calculate a tip says that a shocking amount of people can't do this very basic bit of math.
Apparently there is a significant enough portion of society who need help for this. Hell, I've actually watched people struggle to calculate 10%, which is utterly mind boggling.
I don't know if people are really that stupid, or just so lazy as to have the same damned effect.
Re: (Score:2)
You know, that there exists apps to calculate a tip says that a shocking amount of people can't do this very basic bit of math.
Some of them also help split the bill & can do the tips on each order. Not terribly difficult to do, but made easier with an app.
Re: Still better than that malware Android (Score:3, Insightful)
So does that "freedom" come with the ability to update the OS the day a new version is released?
Without waiting on the carrier?
And the manufacturer?
For up to four years after you bought the phone?
Need to ban these companies (Score:3)
So let me get this straight...
First they downloaded a dodgy version of a free development tool...
Then they completely disabled Gatekeeper, which would have warned them that they were using a problematic version of xcode...
People/Companies who demonstrate such a shockingly poor level of judgement shouldn't be allowed to flip burgers, let alone be near a computer.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 b
Re: (Score:2)
Re: (Score:2)
> I know I had to [disable gatekeeper] because of the number of tools I use as a software developer that wouldn't run otherwise.
I don't want to publicly question your qualifications as a software developer but please explain which tools exactly malfunction made you feel like (permanently?) disabling gatekeeper...
Basically I think that someone who considers disabling gatekeeper to be a good idea should not have an admin account on a Mac. But I may be wrong.
Re: (Score:2)
Yet, they still managed to get their apps inside Apple's walls. They'd make the Greeks proud.
Re:Next... (Score:5, Interesting)
Re: Next... (Score:3)
Re: Next... (Score:2)
I've never once had to wait on Dell (my PC manufacturer) or whatever computer store I bought my computer from to patch my Windows PC.....
Re: (Score:2)
You do, of course, have to wait for your OS vendor (Microsoft) to patch your Windows PC, just the same as I have to wait for My phone's OS vendor (Google) to patch my Nexus device, or an iPhone user has to wait for their phone's OS vendor (Apple) to patch their iPhone. The difference here is that Google pushes those patches faster than Microsoft or Apple.
to further my point, though, since we're talking about phone
Re: Next... (Score:2)
You get updates without waiting for the carrier AND the manufacturer only if you own a Nexus phone - a phone a relatively few people own -- and if the carrier allows it. Verizon (the largest carrier in the US) still blocks immediate updates for Nexus phones
Most security updates aren't hardware specific. If Google pushes an update you still have to wait on both your manufacturer and your carrier unless you are one of the tiny minority of Android users who own a Nexus phone that is not on Verizin and then Goo
Re: (Score:3)
Most security updates aren't hardware specific.
But the system images are. That's kind of the point.
and then Google only promises updates for 18 months
Actually, that's:
- Three years from when the device first became available on the Google Store
- Or, 18 months after the device stopped being sold on the Google Store
For how long does Apple promise to support their handsets?
Apple is currently supporting every phone that has been released since 9/2011
While it is true that the oldest phone Google is directly releasing updates for (Nexus 4) was released on November 13, 2012, the HTC HD2, a Windows phone released in November 2009, has community-released ROMs of Lollipop [xda-developers.com]. Does the i
Re: (Score:3)
What good are the "system images" if you can't update your phone with it -- unless you are one of the tiny minority that have non-Verizon Nexus devices?
Lets look at history:
iPhone 3GS
-release 6/2009
-discontinued 6/2011
-last update 2/2014
Re: (Score:2)
Even if that's not the case would you argue that they shouldn't make a security patch in Android that was found in the Linux kernel because it wasn't "theirs"?
No, and neither would they. Again:
If patches are provided with the report or put into AOSP we are happy to provide them to partners as well.
Since the kernel is part of AOSP, if the kernel is patched, the patches are put into AOSP.
For access to notifications you just swipe down on a locked phone to get to the notification and you swipe right on the actually notification to do some application defined event with it.
And for access to directions, drive times, weather, stocks, and the plethora of other information I can train Google Now to display on my lock screen whenever it might actually be relevant to me (and hide at other times)? Seriously, as much as you think I must hate iOS, I can assure you (as evident by my extensive use of an iPad) that I do not; and choosing another platform over iOS fo
Re: (Score:2)
You claimed that Google shouldn't have to patch WebKit because it was "third party" code. WebKit -- that Google had just as many commits to as Apple -- is much less "third party code" than the Linux kernel, but it is just as much Google's responsibility to patch security holes found in WebKit as it is the Linux kernel if it affects Android.
So are you saying that it is not Google's res
Re: (Score:2)
Google had just as many commits to as Apple
Google had just as many commits to as Apple
So you just change the facts to fit your argument? If you can't even agree with yourself, what makes you think anyone else will? Good day, sir.
Re: (Score:2)
Google had just as many commits to as Apple
Google actually had more commits to the WebKit repository
Re: Next... (Score:2)
If I have 6 Apples and you have 5 Apples
1. I have just as many Apples as you do.
2. I also have more Apples than you do.
Those two statements are not mutually exclusive.
That's just like the old kids riddle "how many months have 28 days?"
Re: (Score:2)
Example:
how many months have 28 days?
12
how many months have just 28 days?
1
Re: (Score:2)
What good are the "system images" if you can't update your phone with it -- unless you are one of the tiny minority that have non-Verizon Nexus devices?
You do realize that iOS updates are system images, right? System images aren't just something for Nexus devices on networks other than Verizon; they're how iOS and Android devices get their OS updates. Period.
Your iDevice literally downloads a disk image and overwrites the system partition. That's how most android upgrades work, as well. In more recent versions of Android, the Google stuff is more decoupled from AOSP, so those components can be u
Re: (Score:2)
Re: (Score:2)
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 [google.com] on Slashdot to a Fandroid who made pretty much the same claim...
Re: (Score:2)
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?
Re: (Score:2)
thanks to Android's lack of updating
You mean thanks to lack of updates from device manufacturers and carriers. Android sees quite frequent updates and, if you own a phone not manufactured by a customer-hating profit-mill (e.g. a Nexus device) on a network that doesn't insist on being a control freak (e.g. anyone but Verizon), you get those updates as they come out.
That Nexus users are in the minority does not negate the fact that the lack of updates for non-Google-branded devices are the fault of the device manufacturers, not that of Google
Re: (Score:2)
Me? I bought a device that gets its updates direct from the OS vendor, just like you did.
So did I. They've now abandoned it for anything other than security updates, even though it was still on sale less than a year ago.
That's why I dumped the Nexus and bought an iPad.
Re: (Score:2)
Re: (Score:2)
If it's anything older than the Air 2, let me ask you this: How are you enjoying split-screen in iOS9?
It's an Air 1, and the split screen is fine, thanks for asking.
Re: (Score:2)
You mean thanks to lack of updates from device manufacturers and carriers.
Technically true, but irrelevant if you actually own a device that isn't being updated. Which is most people that own Android devices.
It's simply a fact that iOS devices are kept up to date much more than Android devices. Whether or not this is Google's fault, or even within their control, is not important. This is part of the fragmented nature of Android, and is quite simply true.
Re: (Score:2)
given the above
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2, Insightful)
The Fandroid response to is that it's great that they have the freedom to have malware. They make it sound like they have all this extra choice but when half a million Android zombie bots appears in China that's obviously the fault of all those morons that had extra choic available to them.
Re: Next... (Score:2)
Re: (Score:2)
Hint: the only way to prevent an app from doing BAD STUFF is for the operating system to prevent it from doing BAD STUFF. Even a human reading the source code has a hard time telling whether that socket it's opening to www.evilserver.com is being used legitimately, or sending your banking passwords to Elbonian hackers. And if the bad code is inserted by the compiler, reading the source is pointless.
If you want security, you need to sandbox the apps, and ensure that Fluffy Kitty Screensaver can't read your b
Re: Serious to get into developer path (Score:2)
Re: (Score:2)
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
Re: (Score:3)
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.
Re: (Score:2)
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
Re: (Score:2)
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 unimp
Re: (Score:2)
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.
Re: (Score:2)
Show me where APPLE has ever implied that their security is perfect?
I'm sure they never said it was perfect, but they've certainly marketed their devices as not requiring the user to think about security. This article [appleinsider.com] highlig
Re: (Score:2)
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 [techcrunch.com] and THIS [pcworld.com].
Oh, and BTW, XCodeGhost DOESN'T seem to affect the U.S. App Store, only China.
Re: (Score:2)
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 [lookout.com]. Further, while Lookout and other solutions can actually scan apps for malicious content on Android, due to
Re: (Score:2)
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 [lookout.com]. 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 Appl
Re: (Score:2)
It's a PHONE, get over it!
To some, it's a phone that can also do some computer-y stuff. To an increasing number, it's a computer than happens to be able to make phone calls. I'm in the latter camp; I hate phones, which is why I carry the device that lets me do more non=phone activities; that my Nexus can also make phone calls is simple a bonus, for those times when a text message or email isn't sufficient and face-to-face communication is not possible.
and WHY does EVERYTHING with Apple HAVE to be some big, dark CONSPIRACY?
Who said anything about a conspiracy? I was just pointing out that it was interest
Re: (Score:2)
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
Re: (Score:2)
So, I really don't think that security measures such as strict sandboxing are such a bad idea.
Neither do I, honestly. But I also think the ability to make an app a device administrator (which, in Android, allows it to traverse sandboxes) is a good idea, as it allows for administration tools to be implemented which otherwise would be impossible. Sandboxing does exist in Android; the fact that there still exists a shared "user" filesystem actually makes the platform more powerful. It also means apps can break their own sandboxes, and I do think Google needs to crack down on that.
Let's say I want to
Re: (Score:2)
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.
A simple way for preventing developers from submitting malware is to make sure you know the developer's identity, and make sure they pay for all the damages and get thrown into jail if they submit malware. And _that_ is what doesn't work against clueless devs.
Re: (Score:2)
Re: (Score:2)
The "free detection" app quoted in the summary is an off-appstore build that must be trusted by the user explicitly. Given this is a "jailbreak team" it's unlikely they'll be bothered to do an in-channel release.
Given that it depends on crossing filesystem protection zones that are disabled for privileged apps which can only run on jailbroken phones, it's unlikely they would be *able* to do an in-channel release, since the thing simply wouldn't work.