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."
3rd Party Responsibility? (Score:5, Interesting)
The responsibility is on 3rd party app developers? Hogwash! If Apple wants full control of the app development & distribution process then they get the full responsibility for the security too. Yes, 3rd party apps need to be smart and act in the best interest of the user but Apple's stranglehold of the environment puts this squarely on their shoulders. Fix it Apple, plain and simple.
Re:Once again proving... (Score:3, Interesting)
I really fail to see how it is Apples fault that a third part App does something.
The whole point of the "walled garden" approach - its ultimate benefit - is that apps that "do something nasty" are not admitted, and those which are, are forced to behave.
That said, TFS really makes it sound it much more scary than it really is - if it could somehow launch Skype in background and make a call, that would be a security issue. This? Skype actually pops up and starts dialing, so the user can break the call right away. And the user will be watching, because you have to have him there to trigger your "exploit" by navigating to the page with the iframe.
I wonder, will it work with a JS timer reloading iframe to the required URL while the phone is locked? It's about the only way I see of actually exploiting this... have the user navigate to some seemingly legit page & stay there, and then have it trigger a bit later. But I very much doubt it would work - does JavaScript continue to execute in Safari when you switch away from it or lock the phone?
Re:Once again proving... (Score:1, Interesting)
Apple should do something -- it has been shown that it is up to the OS maker to handle security, as application makers really can't be trusted with much, if anything. Perhaps have a mechanism with an install manifest that if an app wants to do background tasks, the security is vetted, or the app stays in its cell. This way, unless Apple explicitly approves the app with the functionality, it just won't have the ability to do this. To boot, if an app maker fails to clean up their act, it gives Apple more grounds to yank their app and show them the door.
Take a look at the Windows platform -- there are applications made that don't even support ASLR or DEP, hamstringing Microsoft's attempt at security. Because there is no ROI gotten by making an app play well with others, or even with itself, an app maker really has little to no financial interest in security.
Application makers fail at security. It is up to the OS maker to wall them off, or else the entire platform suffers.
Look at Android and the numerous privacy violations reported to /. by apps reportedly slurping SMS and contact data and uploading it to the blackhat's site. There is a reason that Android is starting to get a black eye when it comes to security, and that is because Google assumed that app makers actually didn't choose to shit where they sleep. Google needs an active app approval process, or the platform will be abandoned for one that does.
Re:Is this *really* only an Apple bug?? (Score:3, Interesting)
Already happened. With Firefox, at that, years ago.
http://secunia.com/advisories/25984 [secunia.com]
Firefox registered a "firefoxurl://" handler, which can call Firefox with arbitrary command line arguments, including malicious javascript.
Apple can't validate every URL that passes through - if they had a magic library that could ensure every URL is completely valid in every context from now to forever, they would have that patented and licensed to everyone. So in the end, the application handling the URL must validate its arguments.
The question is - does this affect the PC clients as well? Does Skype on Windows also have the same problem? Or does it not register any URL handlers so you can't just click a Skype link?
Re:Apple should handle but it's Skype's fault (Score:4, Interesting)
So, in your recommended solution, the user would click a "skype://" link and Safari would prompt him with a necessarily generic message such as "You are about to launch Skype, are you sure?" And when the user confirms this, then Skype would launch and prompt the user with a domain-specific message such as "Call: 1-900-xxx-xxxx - This call may incur additional costs. Are you sure?"
Two clicks for the price of one. Yes, that's the kind of Apple human-computer interface we all know and love.
No, this is not a iOS security vulnerability. Safari, nor the operating system, has any way to know whether the resource offered to the external application is exploitable. Except of course when the external application is provided by the OS itself or by an application included in the built-in suite; such as the example of the "tel://" protocol scheme.
For the confirmation message to be meaningful, it must be presented by the target application--which has intimate domain and context knowledge of the resource. That, or Apple would need to keep track of the context and semantics of each and every protocol scheme and how they can be used.
However, this last one still would not be perfect, for each application is free to use the submitted resource in any way it wants to. There is nothing that prevents Skype from receiving a "skype://" URL and deciding to, say, delete your Skype address book, or initiate an HTTP download.
-dZ.