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."
I wonder if this would work... (Score:2)
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: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:3rd Party Responsibility? (Score:4, Funny)
And in the update tech document, that catalogs the changes, it will give a description of the problem, what has been done to fix it and then "credit to Nitesh Dhanjani for reporting this issue". You know, like all the other security update knowledgebase articles on Apple's site.
Re: (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
Re: (Score:2)
I don't see why this was modded troll.
If this comment was trollish then so was mine.
A little consistency here mods?
Re: (Score:2)
Appreciated Jeff. There are too many here who mod based on whether they agree with the comment or not. And all too often on what platform they like or dislike. It's cowardly.
Re: (Score:2)
Way to jump on the modpoint bandwaggon. If on any other OS an application could end up charging you money by responding to a certain URL type you would place the blame firmly on that application. The OS does not know what's going to cost you money, nor does it know what the application is going to do with the URL it receives, only that it's registered to receive it.
You could claim that apple's app store testing process should catch this, and it's plausible that (for example) Tesco might refuse to sell sof
Re: (Score:2)
[disclaimer: iOS developer]
Apple are right, the responsibility is on the app developers. The data passed in through a URL is untrusted data. It's not just websites that you surf to that can send data to your app this way, other apps can too. That's its designed purpose; to "secure" this functionality on Apple's end would essentially be to remove it.
Applications that tell the system that they handle a URL and then blindly trust data they receive through that mechanism are essentially the same as web
Re: (Score:2)
You are obviously confused, obviously never written an application for anything, and certainly never written an iOS app. Application developers have the ability to create confirmation dialogues and the responsibility to do so. From the nature of the ignorance displayed in your post I would assume you have never used an iPhone and certainly never used an iPhone Skype app. Your false outrage is more annoying than cute.
Apple's only realistic solution would be to reject apps that do not use confirmation dial
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: (Score:2)
Re: (Score:2, Insightful)
Therefore, a curse on both houses.
Re:3rd Party Responsibility? (Score:4, Funny)
"You are coming to a sad realization, Cancel or Allow?"
I know I've heard that somewhere, but for the life of me I just can't remember where...
Re: (Score:2)
Re: (Score:2)
The fix _IS_ simple. "This website is attempting to open XYZ.app. [ ]Allow? [X]Deny?"
Actually I was thinking of something similar to KeyChain access in OSX:
[ ]Always Allow?
[ ]Allow?
[X]Deny?
The 'three tier' prompt is already used in mobile Safari when visiting a site with an invalid or expired authentication certificate.
Re: (Score:2)
Always allow is not really an acceptable option. you are counting on the user to know what the third party application is going to do in every case.
Re: (Score:2)
What for? iOS has no multitasking, so the new app will run in the foreground, in direct view of the user. If the user doesn't like it, he can quit the app. Unless starting random apps really becomes a major sport for troll web sites, occasionally quitting an accidentally started app sounds a lot more efficient than having a confirmation box for every mailto: link.
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: (Score:2)
That doesn't make much sense, though, does it? The only way it would make sense was if you could prove that they've had just as many security flaws as they would otherwise have had if they were more open.
Re: (Score:3, Informative)
You wish...Search for the list of security in Android, it is on here somewhere. Many of them are months (not the 2 weeks of the PDF exploit on iOS) and at least 5 of them are more serious, a couple can be exploited remotely.
Ouch! RIP strawman.
Your "interesting" post only pointed out one iOS security flaw, the "PDF" exploit and it still required the user to [do] someting.
Yeah like follow a link. Very remote chance of that happening, I know.
Your outrage over the URL handlers shows you know nothing at all about application development, url handlers, iOS, iPhones, web browsers, or application security.
LOL yeah I know nothing about those because I think a trivial-to-implement, HTML-based drive-by call activation exploit is a big issue. I'm totally blowing it out of proportion. This was a gigantic fail on Skype's part and Apple shares some blame too. Oh sorry, my ignorance is showing, I WUV APPLE!
I love your signature line touting the most completely insecure mobile environment available today.
The only thing insecure about it is that it doesn't protect stupid and determined users from hurting themselves. I welcome t
Re: (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 w
Re: (Score:2)
Re: (Score:2)
How about Apple puts in a fix to automatically deny this access, UNLESS the app itself overrides that position?
An application has to actively register to receive clicks on links of a certain type. So Skype is saying "if anyone clicks on a link that looks like skype://xxx.xxx.xxx then tell me". The app doesn't receive any random URLs, only URLs that it said it wants to receive. So what you are suggesting is actually happening already.
Re: (Score:3)
that's how it is at the moment
by default, you cannot launch an ios app with a url handler.
the app has to register a url scheme, and include code for handling the call. Apple is pretty pointed in the documentation that you need to consider carefully what might be incoming and treat it with suspicion.
this is a good capability - Skype are just idiots.
Re:3rd Party Responsibility? (Score:5, Informative)
In case anybody was wondering about that documentation, Apple specifically warn against this in the documentation for this API [apple.com]:
And in that Secure Coding Guide, you will read things like this:
Uhm... (Score:4, Informative)
Kopete IM for KDE is the first that pops to my mind.
Re: (Score:2)
Sweet! Make one that calls half of the people "assholes" and the other half "geniuses." That'll leave them scratching their eyes and heads.
Re: (Score:2)
What is your point?
This is about websites, not about programs you've installed yourself. Did you read the headline?
Re: (Score:2)
But you installed Skype. This is a stupid issue, since Apple doesn't know how to validate the data passed via the handler... it's up to the app launched from a (possibly untrusted) source to check it all. Most apps do this, and I would've done it out of habit.
It's a Skype bug that's easy to fix. I'm sure they'll have a patch out in the week.
Re: (Score:2)
But you installed Skype.
knowing that skype could call from visiting webpages in safari? It's not called "skype mobile safari plugin app"
This is a stupid issue, since Apple doesn't know how to validate the data passed via the handler... it's up to the app launched from a (possibly untrusted) source to check it all.
I agree, but only about the stupid issue part. It should be up to the human, the owner of the phone, to check it. But apple wants to remove thinking from their users (spelling correction, not spelling checking).
Apple should handle but it's Skype's fault (Score:2)
Realistically, all registered handlers should be interdicted like the call-interface.
However, I can see how it's in Apple's best interest to leave this to Skype:
I see where Apple doesn't want to do the right thing, and ultimately, it's still Skype's fault that they do
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: (Score:2)
Not all URL handlers point to resources that can be exploited. Apple is right here, it is up to the app developer to determine what the user should have to confirm and what they should not have to.
Re: (Score:2, Informative)
Re:Apple should handle but it's Skype's fault (Score:5, Informative)
It's not just Skype, that was just an example.
ANY app can be opened this way.
That is false. Most apps do not register URL handlers.
Should the small minority of apps that register URL handlers be trusting that when they get a URL tossed at them, the user knows and approves of the app being opened for that purpose? Of course not. That would be inconsistent with how iOS is documented to operate. Safari or any other app sending an OpenURL message has no way to know whether a particular URL scheme has a potentially risky handler on the other end. An app that receives an HandleOpenURL message knows what its URL scheme does and knows whether handling a particular URL might be risky. Some developers seem to be making use of the opacity of that mechanism.
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.
Where do you get that number? The biggest list of registered URL schemes I can find seems to have about 140 listed ("seems" = a crapulous website showing ~10 per page, 14 pages.) Most apps would have no need to register an URL scheme.
Skype dropped the ball here. Their app is doing something potentially costly in response to a system message that Skype knows the user might not have knowingly initiated. The app should be asking the user for authorization before initiating the call. Doing that would be more accurately described as "minimally competent" than "really awesome" unless you consider elementary security awareness "really awesome."
I don't get me wrong. I'm not saying that Apple shouldn't fix the design issue here, they should. But this is a UI design problem more than it is really a security problem. A wisely designed app that needs this functionality can ask for user authorization, but only after it has been launched and put in the foreground. Apple should generalize the integration they use in their own apps to a system-level feature that asks the user for authorization before switching apps whenever an OpenURL is sent that would switch apps. Let apps request quiet switching in their Info.plist and let users toggle that on a per-scheme basis. In the interim, they should go through the app store and remove every app that registers an URL scheme which it handles to do something risky without user authorization.
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.
Re: (Score:2)
No I think he was suggesting that the URL handlers allow the custom confirmation to be launched inside of Safari before even launching the app (like the standard phone number handler in iOS).
Re: (Score:2)
But there's no way for it to know what the handler is going to do prior to calling it! It's like asking Safari to solve the Halting Problem when seeing a URL protocol scheme.
You are predicating this solution on the assumption that the scheme "skype" means "make a VoIP phone call", but it doesn't mean that at all. It literally just means "this scheme is handled by the application Skype, for it knows what to do with it." It could mean "make a VoIP call," but it just as well could mean "write to log file,"
Re: (Score:2)
Re: (Score:2)
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.
A quarter century of experience with Apple's HIG has taught me that "know and love" is not really a suitable phrase. That implies something like a monogamous spousal relationship, while the reality for Apple customers and developers is more like being regulars at the Moonlight Bunny Ranch...
What I'm suggesting is that currently apps have a responsibility to do their own authz dialogs because nothing else does. Ultimately an app that does potentially risky/costly things depending on the specifics of the p
Re: (Score:2)
Re: (Score:2)
ANY app can be opened this way.
If you've registered a URL schema to the OS, and the OS calls up your app when it sees that URL schema... how's that different from any other OS (w/ the associated software suite), like Windows and Linux?
The OS could help by telling your app things like "this URL comes from an Internet URL on Safari".. but it's by no means the OS's fault. It's just doing what it's supposed to do, an intermediary.
Re: (Score:2)
"ANY" app wil not have a URL handler.
Of the few that do, very few of those do anything that would require confirmation. The documentation for App developers clearly tells them to validate input, etc. when launching their app from a URL handler.
You are obviously confused about what a URL handler even is.. Cure that you got modded insightful though.
Re: (Score:2)
If only Skype actually allowed video calling from an iPhone, yes they would be competing with Facetime. Sadly, they don't.
Re: (Score:2)
Is this *really* only an Apple bug?? (Score:5, Insightful)
Re:Is this *really* only an Apple bug?? (Score:5, Insightful)
Re: (Score:2, Informative)
I'm conflicted. On one hand, Skype is sort of known for getting hacked (having had my "Skype account" hacked and a bunch of money charged to my credit card even though I didn't have and never did have a Skype account. It was a pain to sort out but as identity theft goes, not as bad as it could have been.)
So what you're saying is, your credit card number was stolen/skimmed and someone registered a Skype account with it to run up charges?
I fail to see how this is a Skype issue. The same thing could happen with Amazon or any other business that accepts credit cards over the Internet.
Re: (Score:2)
file:///bin/ls on linux asks me to save the file. Firefox here doesn't understand ssh though that may be implementation specific.
Re: (Score:2)
Re: (Score:3, Informative)
Well you ARE telling it its a file... ssh://example.com would be an example of an ssh URL...
Re: (Score:2)
You are wrong on every level and totally confused. I for one am shocked this was not modded insightful.
Re: (Score:2)
Why on earth would the file: protocol have the meaning "maybe execute this file"?
Re: (Score:2)
Historically that used to work on windows. You could launch executables with the browser.
Re: (Score:3, Informative)
Historically that used to work on windows. You could launch executables with the browser.
I'm pretty sure only Internet Explorer behaved badly in that way.
Re: (Score:3, Insightful)
Re: (Score:2)
What is clear is that I don't expect my web browser to launch external programs without my consent. Even starting an email client for mailto: urls annoys me. Displaying a dialog before running an url handler needs to be the default behaviour. I suppose you might want to give the user the option to opt-out of the dialog for an individual protocol on a per-domain basis, although I don't see what the big deal is with quickly displaying a confirmation dialog when I'm leaving the browser.
And while Skype does hav
Re: (Score:2)
I'm just irritated that Internet Config went away with the switch to Mac OS X. Such a simple, powerful idea! It would show you (among other things) a list of protocols, and what helper applications were associated with them, and allow the user to easily make changes. It was one of those little gems that was such a good idea that applications started almost universally supporting it even before Apple got on board. Then Apple made their own UI and shipped it with the OS, and life was good... until Mac OS
Re: (Score:2)
I have literally no idea how to view and change url handlers in Gnome, either. I suppose it's a weird mix between Firefox settings, Gnome settings and maybe some other stuff thrown in for good measure.
There is a "Preferred Applications" preferences panel, which handles the frankly bizarre mix of default web browser, mail app, multimedia player, terminal app (?!) and two accessibility apps. I guess this strange mix of protocol handlers and handlers of other stuff is one of those things that is convenient for
Re: (Score:2)
See, I woudl find it a pain in the ass if my os made me click through a dialog every time I clicked on a mailto link. I just want the browser to get the hell out of my way and let me send some mail.
Re: (Score:2)
Like I said, you could offer an option to disable the popup on a protocol and/or site basis.
Re: (Score:2)
Well, on Firefox on Linux, an application that is registered as the URL handler (e.g., for callto:) is automatically launched when you click on an appropriate URL. No idea about iframes and other trickery. No idea how Skype on Linux works (if it confirms calls), but it's certainly up to the application.
Re: (Score:3, Informative)
When I run a callto: URL in my Firefox/Linux, I get a dialog asking me if I want to open gnomemeeting. It's not opened by default, although there is a checkbox to do that for future invocations.
Re:Is this *really* only an Apple bug?? (Score:5, Informative)
If I write a seemingly harmless application that registers a url handler for the phish: protocol, then I agree that it is the application that is at fault, but I do expect the OS to protect users from this. Android pops up a dialog asking which application you want to handle the protocol - even when there is only one choice, and the user has to explicitly tick the "always use this application" box to skip that confirmation step.
Re: (Score:2)
Protect users from what? They made a choice to install an app (Skype), and the app already has access to the system. Anything malicious it can do, it can do without registering an url handler.
The Android method you're mentioning is valid, too. But with the "It just works" mantra from Apple, I wouldn't expect to be asked "are you sure you want to use skype for 'skype:*' ?"
How could it make sense for the OS to handle this? (Score:2)
As an iOS developer - I kind of agree with Apple. I write apps which register URL handlers - and when one clicks on on - I make the *user* validate that this is what they really want to do.
Another way of looking at it: if you've got an app that accepts an URL handler, do you want a braindead OS policy of asking the user for permission every time? Especially when the OS would likely have to ask, "do you wish to open foobar://1233453987039 with Metapie?"
The only way to avoid that would be for the app to register an URL evaluator and an URL security policy, at which point you may as well just have the app make the decision. It doesn't make any sense for this to be handled at the OS level.
Re: (Score:3, Interesting)
Neat (Score:2)
That's pretty neat, regardless of the obvious harm that it could cause. Set up a small server and trick people into calling you, for the lonely hacker!
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: (Score:2)
In reality, you want any app to be able to use a defined URL handler path without interdiction
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.
Every time I hear about a URL handler exploit I wonder who the hell ever thought that it was a good idea.
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 applic
This just in (Score:5, Insightful)
URL handlers handle URLs. Geeks are shocked.
Re: (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: (Score:2)
Skype comes out the box?
Re: (Score:2)
You must be new around here.
Re: (Score:2)
They haven't said it's not a problem, they've just pointed out that they can't/won't fix it.
If I registered strangeURL://* on a system, the only thing iOS could ask was "Are you sure you want to start StrangeApp? It may or may not cost ya"
If Apple let the app ask the question (as they do now), that question could be much more meaningful.
If Apple were to stick completely to the "Walled garden" approach, they would not have allowed Skype because it doesn't ask that question.
Re: (Score:3)
Actually, it can't make real phone calls, if you try to make a call with a URL via the phone app, it does the right thing and asks the user first. This is a vulnerability in the Skype app, which should not be initiating potentially expensive actions without prompting the user
Re: (Score:2)
But isn't Apple responsible since they allowed the Skype phone to be distributed even without prompting the user?
Re: (Score:2)
Amen. I agree with you 100%. I'm wondering where the outrage to this is, too. And shame on the topic/original story for putting the blame on Skype. This is a serious problem in which sole responsibility lies with Apple.
All Apple has to do is simply put, whoa, wait for it, permissions (available since the beginning of time!) or a simple "do you want to launch program XYZ?" dialog when you click on a punch-the-monkey ad in Mobile Safari.
But no, leave it to Apple to put the responsibility on the developers. It
Re: (Score:2)
Then you both completely misunderstood the problem and have absolutely no idea what you are talking about...What should iOS ask? You installed an app that registers a URL handler, it is in fact up to that app to umm you know properly handle the url. The browser has no idea what that URL actually does, the app handling it does and is responsible for ensuring the user is informed before doing something expensive/dangerous...
This is simply the second story in a week desperately trying to find security flaws
Re: (Score:2)
Then you both completely misunderstood the problem and have absolutely no idea what you are talking about...What should iOS ask? You installed an app that registers a URL handler, it is in fact up to that app to umm you know properly handle the url. The browser has no idea what that URL actually does, the app handling it does and is responsible for ensuring the user is informed before doing something expensive/dangerous...
This is simply the second story in a week desperately trying to find security flaws in iOS and failing miserably.
Apple shill. End user installed an app for wifi based "phone" calls. How do they know if there is a URL handler involved at all? If there are 10,000 apps that need cleaned up, does the onus still fall on the 10,000 3rd parties when apple could easily solve the problem since Apple's app is the one gateway that is causing the issue to begin with?
Re: (Score:2)
Actually I understand the problem all too well.
We live in reality. Not in Apple-theory-fairy-land. In reality, this exploit exists. You can't deny it. Exchange Skype with any of the thousands of VoIP programs on the App Store. It can, and WILL, even happen to a program that stores credit card numbers or secure customer information (say a CRM) on a phone that users will most definitely have set on auto-login. IT HAS HAPPENED. And it will CONTINUE to happen.
Rather than your method of closing your eyes and say
Re: (Score:2)
Whether or not a similar problem exists in competing products is beside the point. [I haven't run into anyone pretending] competing products are implicitly secure straight out of the box[, but I have run into] Apple fans pretend[ing] exactly that.
Fixed that for you
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: (Score:2)
Mark V Shaney, is that you?
Re: (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
Re: (Score:2)
It's probably more to parody you and your other MichaelKristopeitXXX accounts.
Thing is, MichaelKristopeit172 is posting less "pathetic" stuff, if he keeps it up he'll be easily distinguishable from the other MichaelKristopeitXXX accounts by virtue of not being stuck at zero or lower karma.
Re: (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: (Score:2)
Reminds me of my first 'hacking' of the school computers. They were locked down, and relatively well. You could only launch Netscape. There was nothing in the start menu (Running Windows 95).
However, you could reconfigure Netscape to launch any number of 'handlers'. Well I set up the telnet handler to be the Windows Explorer. (The app that launches separate from the desktop lets you browse through the files and such).
Type in "telnet://" sure enough, windows explorer launched and I could do what ever I wante
Re: (Score:2)
If it is done using URL handlers, it requires some apps that is registered as a URL handler. Skype calls would require Skype or something that registers its protocol instead, yeah. But other URL schemes would still launch the applications registered to handle those.
BTW, unless it was a Windows 95 locked down with third-party software, all you really needed to do was reboot and get into safe mode or item-by-item interactive boot with the F8 key. Back in the early 1990s, we used to use the DOS Shell menu item
Re: (Score:2)
Can someone explain how this flaw can be used in real life? Does this mean a web site can tap your phone with skype? Wouldn't it also need access to the volume control as well to avoid the user hearing the Skype tone? Also, I thought the iPhone didn't allow third-party app multi-tasking. So does this mean that the malicious web site would be forced to lose control of the window and cede it to the Skype application instead? If it really did that last one, cede control to the Skype application, I wouldn't rea
Re: (Score:2)
When the URL is actioned, the Skype App is opened in the foreground, and Safari closes down. The user is completely aware that the Skype call is being made.
I agree with you that authorisation dialogs should be avoided as much as possible. But making phone calls from URLs on web pages is something that is abusable enough that it should require authorisation. The number should be displayed, with a "Call" and a "Cancel" button.
As things stand, it's clear here that the Skype app is the one with the security fla
Re: (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
What's wrong with URL schemes? They are secure. (Score:2)
URL schemes are secure as they are. Applications have to define a scheme they will support; you cannot open just any application. Then when the app is launched it goes through a specific method built to handle parsing the specific URL that the application itself asked be used to launch. I don't see the security risk, at all.
Even in the case of Skype, what harm can an attacker really do? The worst I could see would be calling an expensive pay number. But wouldn't Skype have a built-in warning around th
Re: (Score:2)
But wouldn't apple have a built-in warning around that generally no matter what app was called? Shouldn't it? That's why protection of something that can do generic stuff would seem to be in the domain of the initiating application to protect, because Apple cannot know all the possible input paths that trigger damage, so they should defer to the end user (thinking human), not Steve Jobs' Perfect Algorithm.
FTFY
Re: (Score:2)
iPhone is also a trademark of Cisco. I think Apple probably has it covered.
Re: (Score:2)
Of course there is no exploit.. Neato try though.
Re: (Score:2)
I don't get how Apple's position in this is defensible. The whole iOS platform is sold as a locked down walled garden that, and I quote, "just works." This specific incident demonstrates two things to us:
1.) The application approval process doesn't actually protect us as users. We've all known this for a while, and by itself it actually isn't that big a deal.
2.) Apple's bottom line is the only thing the walled garden is protecting. If an application gets through the approval process but turns out to actually have a security flaw, that shouldn't be a big deal in a controlled market environment because you can either pull the application or change the environment to mitigate the issue. That obviously is not what is happening.
So yes, for those of you who are asking, we are actually upset that the iOS platform is both too closed and too permissive. We're complaining because it is closed in all the ways that hurt the consumer and yet isn't closed in any of the ways we were told it would help us. It is the worst of both worlds.
You are apparently upset about nothing at all. What are you suggesting Apple should do? Pull the Skype app? Maybe, but it is not a big security hole, it does not happen in the background. You seem to be upset about a problem that does not exist. It is almost like you were looking for a reason to rail against apple. Oh that is what you were doing.
NM