Malicious Websites Can Initiate Skype Calls On iOS 177
An anonymous reader writes "In this article, security researcher Nitesh Dhanjani shows how iOS insecurely launches third-party apps via registered URL handlers. Malicious websites can abuse this to launch arbitrary applications, such as getting the Skype.app to make arbitrary phone calls without asking the user. Dhanjani 'contacted Apple's security team to discuss this behavior, and their stance is that the onus is on the third-party applications (such as Skype in this case) to ask the user for authorization before performing the transaction.' He also discusses what developers of iOS apps can do to design their software securely and what Apple can do to help out."
Once again proving... (Score:1, Insightful)
...that Apple's products aren't all their fanboy customers hype them up to be. They have security through (still, relative) obscurity on the desktop. In mobile gadgets, where they're somewhat more common, they aren't secure -- and as shown in the quote here, Apple could care less about that. When they have the opportunity to use their walled garden to protect their customers, they don't actually do so, either -- hence proving that the walled garden is only there to protect profits, not customers.
All that greatness, *and* you have to pay over the odds to get it.
Re:Once again proving... (Score:2, Insightful)
Right, because this is clearly a security flaw you'll only find in Apple products.
Re:Once again proving... (Score:4, Insightful)
Whether or not a similar problem exists in competing products is beside the point. Nobody pretends competing products are implicitly secure straight out of the box. Apple fans pretend exactly that.
Or do you think that it's OK that your walled garden iOS product can make calls (potentially to expensive toll numbers) without any prior warning, simply by visiting a malicious website -- and that Apple doesn't think that's a problem?
Re:Once again proving... (Score:3, Insightful)
I was all set to shout; "See!? This is where Android rules!" Then, I thought better of that idiotic statement. Android will have this same issue and more of the same data hijacking apps that every system will contend with. Personally, I can think of worse things than a random skype call. Come on, Saddos! This is how you meet new people in the Golden Age of Social Networking. Get with the program as say hello to your new random friend!
Re:Once again proving... (Score:0, Insightful)
They have security through (still, relative) obscurity on the desktop.
Sorry, but OSX is much less obscure than MS - Darwin, and the BSD tools are open source, so there's no obscurity there. The GUI is more obscure than Linux or the BSDs though, but much less than MS products.
In mobile gadgets, where they're somewhat more common
Uhh.. What!?!? Oh, I get it now - you don't know what "obscurity" means. here:
Obscurity: 1) the quality of being unclear or abstruse and hard to understand. 2) not well known
So.. how exactly is Apple not well known again?
Is this *really* only an Apple bug?? (Score:5, Insightful)
Re:3rd Party Responsibility? (Score:5, Insightful)
Here is how it will go down:
First, Apple say this is an app issue, and app vendors need to fix it. They will dig their heals in and effectively say "screw you" to all their loyal customers.
Then, in the next iOS update (or the one after, if the next update is scheduled to be too soon) there will suddenly be a prompt for launching applications via registered URL handlers, possibly with some hype about how Apple is looking out for you, but not necessarily.
When confronted about the dichotomy between their two positions, Steve Jobs will simply reply "Apple is always concerned about the security of our customers, of course we would want to protect them from these kinds malicious attacks." All the while giving the reporter a befuddled look, as if to suggest the reporter is crazy for even asking such a stupid question.
Re:Apple should handle but it's Skype's fault (Score:4, Insightful)
It's not just Skype, that was just an example.
ANY app can be opened this way.
It's definitely Apple's problem. Skype could have been really awesome fixed the problem on their end, but that would not have solved the problem for the 200,000 other apps that can be launched this way.
Re:Is this *really* only an Apple bug?? (Score:5, Insightful)
Why are you wanting to close this down generally? (Score:3, Insightful)
It's odd to me that so many people on Slashdot who complain about platform openness on the iPhone, are suddenly eager to close down a channel of functionality.
In reality, you want any app to be able to use a defined URL handler path without interdiction - imagine a flow of photo editing apps where you use two or three, it's already slightly jarring to switch apps, why would you want a system dialog in the middle of that flow for each call?
It really does make a lot more sense for some application that has a protected resource it allows custom URL handlers to activate, to place protection in front of that to be confirmed by the user - Apple does it with the call mechanism, any app that makes a call does prompt the user to confirm a call is desired. So Skype should in fact follow suit, but we should harm the flow of data between other applications in the system just because one app developer is a bit weaker on security.
Can you really call pay numbers via skype anyway? I would have thought that would cause skype to verify you really wanted to make a paid call, regardless of the number coming in via an outside source or the user typing it in... if you can't make a call on skype that costs anything, then securing it seems kind of moot since there'd be little point in an attack.
Re:Is this *really* only an Apple bug?? (Score:3, Insightful)
This just in (Score:5, Insightful)
URL handlers handle URLs. Geeks are shocked.
Re:3rd Party Responsibility? (Score:4, Insightful)
Yeah, the fix should be simple. Add this to the list of requirements for apps and don't approve any that don't implement it.
The fix _IS_ simple. "This website is attempting to open XYZ.app. [ ]Allow? [X]Deny?"
Re:3rd Party Responsibility? (Score:5, Insightful)
So the curated iOS apps really then are the same as any other "Open" platform apps that user can download and install themselves. The only difference of course is that Apple get their 30% and are in a better position to control their platform - all nicely in the name of the user benefits!
You beat me to it, the "quality, security and support" arguments for curated app stores are DEAD now. Quality was a stillborn argument, security was quickly disproven, and now this support is the last nail in the coffin. When it came time for Apple to put their money where their mouth is, they offered a level of support that would only be acceptable for an amateur FOSS project (basically none, much like the weeks when the PDF exploit used by jailbreakme.com went unpatched) - except you can't even fix it yourself. And you're paying game console prices.
Re:Once again proving... (Score:5, Insightful)
I really fail to see how it is Apples fault that a third part App does something.
When you require that EVERY application that can run on your platform be approved by your personnel for sale, I'd say that you bear some (though by no means all) responsibility for the application's behavior.
Re:Once again proving... (Score:3, Insightful)
If you require all URL schemes novel to the system to be validated by the user before they launch the other application, then you just end up with the "Are you sure you want to do that?" problem we all loved on Vista. Some application-defined URL schemes trigger Really Big Things (like Skype calls), and some just launch the app, it's up to the developer who decided to invented the scheme to actually describe what the scheme does. It's obviously impossible for the host OS to test an arbitrary URL to see if it "does something bad" or not, since that would require the OS solving the halting problem on the target app for the given input.
Of course you could point out that this is a side-effect of the fact that URLs are pretty much the ONLY way to do application-level IPC on iOS. Since URLs are highly containable, don't let apps share memory, are rigorously parseable, etc. they present a very thin vector for making Bad Things Happen, compared to anything else.
Thank you. (Score:1, Insightful)
You have added the first rational comment to this conversation. There is no security flaw here. Browsers also handle certain URLs. Those may be malicious, also. Does that make the browser insecure? No. It is doing what it was designed to do.
Browser cannot run arbitrary applications (Score:3, Insightful)
No I don't. In fact, I just want a web browser that's a web browser, and is completely lacking the ability to run arbitrary programs on the host machine.
And that's what you have. The web browser can only launch apps where the app itself defines EXACTLY the URL schemes that it accepts, the app can only be launched if you use a link of the form the application expects - and then the application will be launched into a method explicitly built to handle that launch path.
The URL scheme is a great way for applications to transfer data between themselves, as in the example I gave where a photo can be transferred between a few different photo editing applications. We have only one instance here where THEORETICALLY it could be a problem that a web link can trigger a skype call, even though no-one has yet laid out the path where that costs the user any money without interdiction (does the Skype app really let you call pay numbers that are entered even by hand? That seems like an issue by itself).
Re:3rd Party Responsibility? (Score:2, Insightful)
Therefore, a curse on both houses.
Re:3rd Party Responsibility? (Score:2, Insightful)
I believe iOS doesn't come by default with a url-binding for skype: it gets setup when skype installs.
you're sugesting a change from:
no binding -> skype install -> binding added
to:
no binding -> skype install -> locked-by-default binding -> skype override -> unlocked binding
Straight away the skype install would change to both add and unlock and you're back to exactly the same position as before.
As much as it pains me to say so I'm with Apple on ths one: The app install created a url binding. It's then up to the app to handle those urls sensibly.
Re:This just in (Score:1, Insightful)
slashdot = stagnated
Re:3rd Party Responsibility? (Score:3, Insightful)
Here is how it will go down:
First, Apple say this is an app issue, and app vendors need to fix it. They will dig their heals in and effectively say "screw you" to all their loyal customers.
Then, in the next iOS update (or the one after, if the next update is scheduled to be too soon) there will suddenly be a prompt for launching applications via registered URL handlers, possibly with some hype about how Apple is looking out for you, but not necessarily.
When confronted about the dichotomy between their two positions, Steve Jobs will simply reply "Apple is always concerned about the security of our customers, of course we would want to protect them from these kinds malicious attacks." All the while giving the reporter a befuddled look, as if to suggest the reporter is crazy for even asking such a stupid question.
After this, Apple users on Slashdot will defend Steve Jobs. They'll state this can happen on any operating system, and that it is not Apple's responsibility. Then they're say how they are immune to viruses. They'll rejoice when they get their new version of Safari, which is limited to Apple's pre-approved sites.
Then their call will cut out, their screen will break, and their data will disappear. Steve Jobs will tell them that they are "holding it wrong". Apple fans will then bend over and take this abuse, at a personal cost of $4000.