×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Malicious Websites Can Initiate Skype Calls On iOS

Soulskill posted more than 3 years ago | from the buck-passing dept.

Communications 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

177 comments

GOOD! (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34168692)

Stupid Macfags. Fuck Apple products with a rubber dick. Then break it off when it's far up their faggot asses. Niggers.

Re:GOOD! (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34168800)

I lol'd.

Re:GOOD! (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34169228)

Take the skinheads bowling, take them bowling
Some people say that bowling alleys have big lanes
Some people say that bowling alleys all look the same
There's not a line that goes here that rhymes with anything

Once again proving... (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34168748)

...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... (2, Insightful)

MrEricSir (398214) | more than 3 years ago | (#34168794)

Right, because this is clearly a security flaw you'll only find in Apple products.

Re:Once again proving... (4, Insightful)

Anonymous Coward | more than 3 years ago | (#34168846)

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... (0, Troll)

MichaelKristopeit162 (1934888) | more than 3 years ago | (#34169238)

did apple install skype on the user's device? did apple register the URL handler?

Re:Once again proving... (0)

Anonymous Coward | more than 3 years ago | (#34169760)

Did Apple allow the handler app to open itself and close the browser without user confirmation?

Hint: the answer is yes.

Re:Once again proving... (0, Troll)

MichaelKristopeit119 (1933106) | more than 3 years ago | (#34169980)

i'm confused... so do you believe the user should or should not be allowed to install 3rd party software that does what they ask of it?

or would you rather have a dialog pop up every time you open a mailto: link?

Hint: you're a retard

why do you cower? what are you afraid of?

you're completely pathetic.

Re:Once again proving... (0, Troll)

MichaelKristopeit172 (1936956) | more than 3 years ago | (#34170058)

I would rather have a pathetic:MichaelKristopeit link always reply "Yes, pathetic".

Re:Once again proving... (0, Troll)

MichaelKristopeit118 (1933104) | more than 3 years ago | (#34170224)

"MichaelKristopeit172" is operated by an individual attempting to steal my identity.

to the cowardly individual responsible: present yourself to me, admit what you've done; and i'll bring upon you the ultimately punishment for your transgressions.

you're COMPLETELY pathetic.

Re:Once again proving... (-1)

hsmith (818216) | more than 3 years ago | (#34169278)

I really fail to see how it is Apples fault that a third part App does something.

Re:Once again proving... (4, Insightful)

Zak3056 (69287) | more than 3 years ago | (#34169342)

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... (2, Interesting)

shutdown -p now (807394) | more than 3 years ago | (#34169580)

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... (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34170004)

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:Once again proving... (1)

MrEricSir (398214) | more than 3 years ago | (#34170112)

Nobody pretends competing products are implicitly secure straight out of the box.

You must be new around here.

Re:Once again proving... (2, Insightful)

countSudoku() (1047544) | more than 3 years ago | (#34168854)

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... (1)

0100010001010011 (652467) | more than 3 years ago | (#34168938)

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 wanted. I had hidden folders of ... archived images.

Oh the good ole days. This was ~1999-2000ish.

And doesn't this also require you to have Skype installed?

Re:Once again proving... (1)

mr_mischief (456295) | more than 3 years ago | (#34169032)

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 in MS Works on our school network to break out of the "security" the main lab had in place. We used to play Scorched Earth and Stunts rather than write papers we could just as easily type up at home. Keep your porn to yourself, perv. ;-)

Re:Once again proving... (0)

Anonymous Coward | more than 3 years ago | (#34168988)

Right. Because that is exactly what the OP was claiming.

Learn to read - before you go on being apple's bitch.

Re:Once again proving... (0, Redundant)

AnonymousClown (1788472) | more than 3 years ago | (#34169026)

Right, because this is clearly a security flaw you'll only find in Apple products.

The GP means is that Apple implied that their platform was more secure and the fanboys loved to point out that they were secure whenever a vulnerability was found in Windows - granted that was more MS hatred than anything.

The GP was only shoving it in everyone's faces that Apple products are not as secure as everyone believes. Of course, us old timers remember all the viruses that were spread disk to disk back in the 80s on the original Macs - so we've never believed the hype about the "safety" of Apple products.

Re:Once again proving... (0, Insightful)

Anonymous Coward | more than 3 years ago | (#34168874)

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?

Re:Once again proving... (0)

Anonymous Coward | more than 3 years ago | (#34169116)

Somebody is being obtuse -- or perhaps that's another word you'll pretend not to understand the meaning of.

obscure

5. inconspicuous or unnoticeable: the obscure beginnings of a great movement.

6. of little or no prominence, note, fame, or distinction: an obscure french artist.

7. far from public notice, worldly affairs, or important activities; remote; retired: an obscure little town.

Random House Dictionary

Other dictionaries provide similar, applicable definitions. Of course, you already knew that. "Security through obscurity [google.com] " is not an uncommon expression, especially in relation to Apple's products.

Who the hell modded your post insightful?

Re:Once again proving... (1)

stephanruby (542433) | more than 3 years ago | (#34169232)

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 really consider this a major security risk.

And no, I'm not an Apple fanboy, nor am I an iPhone developer (thus the silly clueless questions on my end), I don't even own an iPhone. I am however a former Nokia user who used to be really pissed off at having to authorize every little action my phone had to take.

Re:Once again proving... (1)

MichaelKristopeit140 (1934372) | more than 3 years ago | (#34169316)

yes, it cedes control... they are claiming it's a problem because it could initiate a toll call...

if the user installed skype and skype installed the URL handler, what is apple supposed to do? if this is being done via redirects, and the URL handler is different in the redirect, i guess they could pop-up a confirm dialog, but that would be very annoying if your web app used many different URL handlers like many content management systems do.

like apple suggested, this is up to the 3rd-party application that installed the URL handler, but it would probably help if the web browsers passed along information about whether or not the request happened as part of a redirect.

Re:Once again proving... (2, Insightful)

iluvcapra (782887) | more than 3 years ago | (#34169364)

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.

Re:Once again proving... (0)

Anonymous Coward | more than 3 years ago | (#34169550)

YOU are the asshat putting Apple up on a pedestal, not them.

What's wrong with URL schemes? They are secure. (1)

SuperKendall (25149) | more than 3 years ago | (#34169562)

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 that generally no matter how such a number was called? Shouldn't it? That's why protection of something that can cost real money would seem to be in the domain of the application itself to protect, because Apple cannot know all the possible input paths that trigger money to be spent.

Re:Once again proving... (1)

tqk (413719) | more than 3 years ago | (#34169710)

Blockqote [sic] What you said. Pthoo. [sorry, not even trying to be civil atm]

Can we have a "Party Line" thumbnail please? I'm so fscking bored of hearing about Apple tech I never intend to fall for. /. doesn't consider Apple high tech, from what I've seen, so why such a big Apple footprint?!? Tell Bing about all the wonderful stuff Apple things can do. They might like to hear about it. Seeing it here just irritates me. Nice hardware and user interface, but user, developer, and universe is a walled garden/fascist/oligargichal/corporatist dictatorship ! @#$ Or whatever, and I'd rather stay away from that sort of thing (poor; can't afford anyway).

Sorry, /rant

I don't even recommend Apple to family any more. I build 'em a FLOSS laptop of some sort. Solved.

3rd Party Responsibility? (5, Interesting)

WrongSizeGlass (838941) | more than 3 years ago | (#34168752)

[disclaimer: Mac & iPhone user]

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? (0)

Anonymous Coward | more than 3 years ago | (#34168916)

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.

Re:3rd Party Responsibility? (3, Insightful)

Culture20 (968837) | more than 3 years ago | (#34169174)

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? (1)

immaterial (1520413) | more than 3 years ago | (#34169354)

Suddenly the user has to click through confirmation dialogs every time they click a mailto: link, or click a link to a stream that would open in VLC, or any number of other things that are completely innocuous. This issue with Skype is that it initiates the call immediately without user interaction - that's like if you clicked a mailto: link and your mail client just went ahead and sent the email immediately. It's pretty clearly a problem with the app.

Re:3rd Party Responsibility? (0, Troll)

MichaelKristopeit122 (1933778) | more than 3 years ago | (#34169374)

i don't understand... if it's so clearly a problem with the app, then how come every post claiming this is a security flaw on apple's part is moderated +5 insightful?

oh, right...

slashdot = stagnated

Re:3rd Party Responsibility? (0)

Anonymous Coward | more than 3 years ago | (#34169714)

Are you still here? Maybe I should go register one of those MK### accounts ... there sure are a bunch of numbers left.

Re:3rd Party Responsibility? (2, Insightful)

jhoegl (638955) | more than 3 years ago | (#34169552)

It is the app causing the problem, but Apple allowed the app.

Therefore, a curse on both houses.

Re:3rd Party Responsibility? (1)

MichaelKristopeit128 (1934222) | more than 3 years ago | (#34169360)

that fix _IS_ annoying... have you ever used a content management system before? do you want to have to confirm that you want to open every single piece of media that requires an external program?

did you want to name the pop-up dialog "clippy" or did you come up with something more user-friendly?

Re:3rd Party Responsibility? (1)

WrongSizeGlass (838941) | more than 3 years ago | (#34169680)

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:3rd Party Responsibility? (0)

Anonymous Coward | more than 3 years ago | (#34168970)

Testing 3rd party apps when there are 300,000 apps in the App Store is just impossible. On the other hand Apple promises users security and quality via tight-control and that just isn't practically feasible. They can catch *maybe* the most obvious bugs if they pay some attention (which I doubt they do) but claiming anything other than that is a lie.

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!

Re:3rd Party Responsibility? (4, Insightful)

GameboyRMH (1153867) | more than 3 years ago | (#34169230)

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:3rd Party Responsibility? (4, Insightful)

Bigjeff5 (1143585) | more than 3 years ago | (#34168974)

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? (3, Funny)

jo_ham (604554) | more than 3 years ago | (#34169046)

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:3rd Party Responsibility? (3, Insightful)

tbird81 (946205) | more than 3 years ago | (#34170040)

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.

Re:3rd Party Responsibility? (0)

Anonymous Coward | more than 3 years ago | (#34169028)

Yeah Apple, ya douches. Fix it like he said. Gah..

Re:3rd Party Responsibility? (0)

Anonymous Coward | more than 3 years ago | (#34169162)

You're an idiot and don't understand the first thing about the issue here. If Skype wants to allow arbitrary calls from a URL handler then that is their problem. Nothing to do with apple. They are doing the right thing by executing the registered action for a given URL.

Re:3rd Party Responsibility? (0)

Anonymous Coward | more than 3 years ago | (#34169292)

Disclaimer: Also a Mac and iPhone user
While I can see and respect your viewpoint, this is the wrong way to go about this. Have we learned nothing from the Windows Vista UAC debacle? Prompting the user every time they try to launch something will just lead to users ignoring the prompt.

This is an issue for the app developers. The API allows for app developers to add in these hooks, and yes these will switch you to that app and potentially do something. That's the entire point!
If that operation is then something that could potentially be used maliciously, such as placing a phone call through skype to any specified number, then it most certainly the job of the app developer to properly catch for and warn the user.

The end user doesn't want to see a confirmation dialog every time they click a "Open this in APP NAME HERE" link that they specifically bookmarked. That someone maliciously coded a site to launch these calls shouldn't matter, as these calls typically do benign things like open up a page in a downloader app. If it was doing something more dangerous, the app writer should code for it.

At most, Apple could add in what they have done for applications in OS X, and warn on the first launch that "This link is requesting to open APP NAME do you wish to proceed?" and then have an option to ignore the prompts. The issue there is it just becomes a burden to the interface without providing any real security benefit.

Re:3rd Party Responsibility? (0, Flamebait)

pgmrdlm (1642279) | more than 3 years ago | (#34169490)

How about Apple puts in a fix to automatically deny this access, UNLESS the app itself overrides that position?

Apple can say they resolved the issue and now it is solely on the application itself for overroding the setting. This also would not make the user constantly verify they want to do something, UNLESS the application itself requested that type of input.

By the way, I hate apple as much as I hate Microsoft.

Re:3rd Party Responsibility? (2, Insightful)

FilthCatcher (531259) | more than 3 years ago | (#34169708)

Umm i think that's kind-of how it already is..
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:3rd Party Responsibility? (1)

iluvcapra (782887) | more than 3 years ago | (#34170056)

It seems like if they did this, Apple would be accused of furthering their third-party-app-as-second-class-citizen agenda... "Look! All of Apples first party iOS apps 'just work,' but third party apps make the user jump through hoops!" (they might be heard saying.)

Uhm... (4, Informative)

larpon (974081) | more than 3 years ago | (#34168756)

Anyone using the Skype public API can make apps that call someone.
Kopete IM for KDE is the first that pops to my mind.

Re:Uhm... (1)

GuldKalle (1065310) | more than 3 years ago | (#34170300)

What is your point?

This is about websites, not about programs you've installed yourself. Did you read the headline?

Apple should handle but it's Skype's fault (1)

rsborg (111459) | more than 3 years ago | (#34168908)

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:

  1. Skype is competing with their FaceTime and Phone/SMS interfaces.
  2. If Apple were to implement generic protocol handler inderdiction/approvals, this opens up a huge can of worms and it Apple begins to own the problem (more than they currently do).

I see where Apple doesn't want to do the right thing, and ultimately, it's still Skype's fault that they don't allow the user to approve call links.

Re:Apple should handle but it's Skype's fault (3, Insightful)

Bigjeff5 (1143585) | more than 3 years ago | (#34168990)

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:Apple should handle but it's Skype's fault (1)

mini me (132455) | more than 3 years ago | (#34169220)

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:Apple should handle but it's Skype's fault (1, Informative)

Anonymous Coward | more than 3 years ago | (#34169280)

>> ANY app can be opened this way.

Wrong. No app can be opened this way unless they register a URL handler. And if they do, that is not in itself a security flaw. I wrote an app that registeres a handler and can be told to open a document. So a webpage could conceivably open my app. Not a practical flaw because people would have to have that app installed, then there would have to be an action that contains a security flaw that can lead to remote code execution. In other words, there is nothing here, and you don't know what you're talking about..

Re:Apple should handle but it's Skype's fault (0, Troll)

MichaelKristopeit123 (1933780) | more than 3 years ago | (#34169462)

i don't understand... if he doesn't know what he's talking about, then why is he moderated +5 insightful?

oh right...

slashdot = stagnated

Re:Apple should handle but it's Skype's fault (2, Informative)

atchijov (527688) | more than 3 years ago | (#34169296)

First of all, please check your facts before making such a broad assumptions. Application need to be configured in particular way in order to be invocable via URL in iOS. I will be surprised if 1 in 1000 applications in Apple iTunes App Store using this functionality. Secondary, It is 100% application responsibility to act "properly" when invoked via URL. All iOS does is firing app and informing it that it was invoked via URL. Skype choose to start call without getting confirmation from the user. Too bad for Skype.

Re:Apple should handle but it's Skype's fault (5, Informative)

wkcole (644783) | more than 3 years ago | (#34169932)

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.

Is this *really* only an Apple bug?? (5, Insightful)

bradgoodman (964302) | more than 3 years ago | (#34168928)

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. The same kind of exploits could be done on PCs - if you had a URL handler - like "SSH" which blindly allowed a third-party URL-click to launch SSH on your PC and log into a site - or even to do the same thing with *skype* URLs. Has anyone verified if these kind of behaviors would or would not happen on a PC or Linux machine?

Re:Is this *really* only an Apple bug?? (4, Insightful)

je ne sais quoi (987177) | more than 3 years ago | (#34169002)

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.) On the other hand, I seem to recall that a big complaint of Windows was that it was too easy for someone to make use of a security flaw in an application because all the applications ran under administrator privileges. This smells the same way, too easy to "one-click" your way to identity theft.

Re:Is this *really* only an Apple bug?? (2, Informative)

Anonymous Coward | more than 3 years ago | (#34169184)

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:Is this *really* only an Apple bug?? (1)

MichaelSmith (789609) | more than 3 years ago | (#34169044)

file:///bin/ls on linux asks me to save the file. Firefox here doesn't understand ssh though that may be implementation specific.

Re:Is this *really* only an Apple bug?? (1)

gman003 (1693318) | more than 3 years ago | (#34169110)

file://c:/cygwin/bin/xterm.exe also prompts to save file (with a warning the .exe's are potentially dangerous), on Vista, using Chrome. Looks like even Windows is smart enough to not blindly execute URLs.

Re:Is this *really* only an Apple bug?? (1, Informative)

Anonymous Coward | more than 3 years ago | (#34169214)

This is not at all what the article is about. The iPhone won't execute random URLs either. This is only for apps that have explicitly registered their own protocols (like skype). So if you open skype://call?somecontact it will open skype and try to call that contact. Same exact thing happens on Windows with Skype installed, and it is exactly the same non-issue there.

Re:Is this *really* only an Apple bug?? (2, Informative)

XMode (252740) | more than 3 years ago | (#34169244)

Well you ARE telling it its a file... ssh://example.com would be an example of an ssh URL...

Re:Is this *really* only an Apple bug?? (1)

blueg3 (192743) | more than 3 years ago | (#34169246)

Why on earth would the file: protocol have the meaning "maybe execute this file"?

Re:Is this *really* only an Apple bug?? (1)

MichaelSmith (789609) | more than 3 years ago | (#34169256)

Historically that used to work on windows. You could launch executables with the browser.

Re:Is this *really* only an Apple bug?? (2, Informative)

enoz (1181117) | more than 3 years ago | (#34169792)

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:Is this *really* only an Apple bug?? (2, Insightful)

emt377 (610337) | more than 3 years ago | (#34169154)

"Kind of"? Clearly the helper app has to do any validation and authentication since it has domain specific knowledge. How would the browser know to confirm, say "do you wish to call 1-900-xxx, this will incur a charge?" or "Upgrade CrapWare from 1.x to 2.3 for $19.99?" All the browser can ask is "really run helper App A?" Which may not mean anything to a user and they have no idea whether they want to or not. The fact that anyone can create a link or content that causes Skype.app to make a call really is a problem with Skype, not the browser...

Re:Is this *really* only an Apple bug?? (1)

moonbender (547943) | more than 3 years ago | (#34169534)

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 have domain specific knowledge, it does not know whether the URL is coming from a trusted context or not. In a desktop environment, I might add links to Skype call urls on my desktop, I wouldn't want a confirmation when running those.

Re:Is this *really* only an Apple bug?? (1)

blueg3 (192743) | more than 3 years ago | (#34169466)

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:Is this *really* only an Apple bug?? (2, Informative)

moonbender (547943) | more than 3 years ago | (#34169584)

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?? (4, Informative)

jrumney (197329) | more than 3 years ago | (#34169488)

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.

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.

How could it make sense for the OS to handle this? (1)

sco08y (615665) | more than 3 years ago | (#34169696)

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.

IOS ? (0, Offtopic)

ivan_w (1115485) | more than 3 years ago | (#34168954)

IOS ?

Isn't that CISCO's router OS ?

(I remember IBM having to rebrand their own (formally OS/400) own OS for IBM i systems from i/OS to IBM i5 OS because they feared a CISCO suit)..

enable
conf term
interface eth0
no shutdown
exit
write
exit

--Ivan

Re:IOS ? (0)

Anonymous Coward | more than 3 years ago | (#34168994)

Apple has licensed Cisco trademarks. And it's iOS, not IOS.

Re:IOS ? (0)

Anonymous Coward | more than 3 years ago | (#34169274)

en
conf t
int eth0
no sh
exit
write
exit

Neat (1)

pieisgood (841871) | more than 3 years ago | (#34168956)

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? (2, Insightful)

SuperKendall (25149) | more than 3 years ago | (#34169136)

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:Why are you wanting to close this down generall (1)

0123456 (636235) | more than 3 years ago | (#34169164)

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 (2, Insightful)

SuperKendall (25149) | more than 3 years ago | (#34169530)

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).

This just in (5, Insightful)

blueg3 (192743) | more than 3 years ago | (#34169170)

URL handlers handle URLs. Geeks are shocked.

Re:This just in (0)

Anonymous Coward | more than 3 years ago | (#34169224)

"Since applications on iOS run in full-screen mode, this can be an annoying and jarring experience for the user."

OMG malicious apps that can insecurely annoy me!

Thank you. (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34169510)

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.

Re:This just in (2, Insightful)

MichaelKristopeit162 (1934888) | more than 3 years ago | (#34169738)

there hasn't been a geek on this site in years... more like "URL handlers handle URLs... marketeers attempt spin"

slashdot = stagnated

Not sure if it's worthy of a mention but (1)

joshier (957448) | more than 3 years ago | (#34169334)

iTunes prompt for password just popped up when I loaded safari to visit slashdot homepage. iPod touch 4g

Anonydude (0)

Anonymous Coward | more than 3 years ago | (#34169546)

Apple has all the right in the world to say they aren't responsible for security... The Walled Garden ain't what she used to be. Jailbreak is legal. How can they be held responsible for what happens once it leaves the factory?

Disclaimer: I got No Apple Nada.

different expectations (0)

Anonymous Coward | more than 3 years ago | (#34169800)

It's funny how, if you unwrap your new Dell PC and find the keyboard too mushy, it's Microsoft's fault, but when there's an exploit on iOS in an ecosystem where each and every app is approved and sold by Apple, then "the onus is on the third party developer".

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...