Apple Addresses URI Handler Issues

das writes "Apple released Security Update 2004-06-07 via Software Update. From the brief description: 'Security Update 2004-06-07 delivers a number of security enhancements and is recommended for all Macintosh users. [...] Mac OS X will now present an approval alert when an application is to be run for the first time either by opening a document or clicking on a URL related to the application.'" This also fixes some related security problems with Terminal.app, Safari, and DiskImageMounter. No word in given regarding how the average user should know whether or not to approve the request.

Comments

No word?

[daveschroeder]

"No word in given regarding how the average user should know whether or not to approve the request?"

Well, first of all, this security update takes the issue completely from the realm of a an automated exploit that could execute arbitrary code simply by visiting a web page with no user interaction or warning, to what can now only be described, more or less, as a social engineering exploit. If you download a new application, like, say an RSS reader, the OS will prompt you to add, for example, the 'feed:' URI handler:

- ONLY the first time, and

- ONLY if it's invoked remotely, e.g., via a web page, URL in an email message, etc.

And since the only value of this exploit came from it being used in two HTML frames with two META REFRESH tags, via a browser, to cause some type of remote volume to mount (or a file to download) AND then have the newly registered URI remotely called, this completely and totally fixes the issue, without hurting the normal functionality of having new URIs get registered when you launch an application. Saying "No word in given regarding how the average user should know whether or not to approve the request" is tantamount to saying that no guidance is given on whether or not a user should even know to open, say, a shareware app they've downloaded for the first time.

On the other hand, if a user is innocently visiting a web site and a dialog box all of a sudden appears prompting the user to accept that *an application* be run, I think it's pretty clear that this handles the issue. This addresses the core of the issue, which was several OS features interacting to essentially enable an automated exploit; that capability is now completely disabled. Apple even went further and removed some suspect handlers (disk:) completely, even though this fix makes it unnecessary.

Also, detailed information on what exactly was changed is here:

http://www.info.apple.com/kbnum/n61798

...as well as a description of what exactly occurs if this situation is encountered:

http://www.info.apple.com/kbnum/n25785

You can verify that these issues are fixed by using the following test site: http://test.doit.wisc.edu/

Re:No word?

[yotaku]

"On the other hand, if a user is innocently visiting a web site and a dialog box all of a sudden appears prompting the user to accept that *an application* be run, I think it's pretty clear that this handles the issue."

Yes just like a windows user knows to say no to those ActiveX dialogs. I'm sorry but this does NOT solve the problem. Research shows that when a user is exposed to such a dialog they get confused and pick a random option.

This is a fix for semi-intelligent computer users. It does not help the average user. If this really worked then no-one would still be installing Gator.

Re:No word?

[Anonymous Coward]

Exactly what I was thinking. This already occurs quite frequently in Windows and most people just click Ok when it comes up. That is why I have to clean a ton of spyware off people's computers.

Re:No word?

[baur]

You think much more highly of the average user than I do.

If you have that low an opinion of people, then you should realize that there is almost nothing that can be done to protect them. At some point, a user has to be allowed to run programes - and new ones at that. If not, then the computer is nearly useless.

Social engineering is always possible. Heck, there are windows viruses that spread using a password protected zip file. That means that the user has to be convinced to download the file, open it, put in a password and then run the trojan. Sure, some people are dumb enough to go through all of that (the fact that its spreading at all is proof of that) - but how many hoops are reasonable to jump though to protect the user? At some point, the OS has to step back and let the user do what they want, or else they'll go use something that gives them more control.

Re:No word?

[jdb8167]

Unlike windows, running a new, untrusted application installed from the browser is a very unusual circumstance on the Mac. It just doesn't happen. For most users, a new application is installed in /Applications. Since you can't do that without an Admin password, any legitimate Application already has to be installed with a users consent.

Users definitely need a quick tutorial on this potential security issue, but if and when they get this dialog they will know something is up. If they are running a new plug-in that they explicitly want, they simply click OK, if not then click Cancel and report the incident as suspicious.

Nothing should ever be installed on your computer via a browser without your express consent. Knowing when to accept or not isn't as big a problem as it is made out to be.

Re:No word?

[merdark]

IMO, the way this should work is to disallow an app to be executed for the first time, period, except explicitly.

This is what clicking 'Yes' in the dialog box does. Explicitly runs an app.

There should be no dialog asking them if they want to open it for the first time, it should simply be disallowed, period.

This you may as well remove the functionality completely, considering you just removed the only way to run a handler explicitly.

There is no way around this. Either a user knows that an app is safe to run, or they don't. I haven't tried it yet so I don't know if this is the case already, but the ONLY solution to the user problem is the solution taken by windows. Every time the dialog pops up, put a phrase saying "If you don't understand, click no because you could be hax0red".

Re:No word?

[pudge]

This is what clicking 'Yes' in the dialog box does. Explicitly runs an app.

The user doesn't understand that, let alone its implications. Users are stupid. You must assume, for the sake of security, that the dialog reads "Kdas Huhuadsd Dudhasd Zdhasd." They will not understand it. I am not trying to be mean, I am not trying to be a snob, I am just being realistic.

This you may as well remove the functionality completely, considering you just removed the only way to run a handler explicitly.

Remove the URI handling functionality? If that is what you mean, you're missing the point. You must run the app the first time. After that, a handler for it will work. The issue is a new app sneaking its way onto your system and being executed remotely.

Every time the dialog pops up, put a phrase saying "If you don't understand, click no because you could be hax0red".

It would be far better if the language were this strong (it is not), but even still, most users won't understand it. You must assume they won't understand the question you are asking them, because the fact is, they won't.

And again, I am only so strict about this because it is a remote attack. Yes, users, can do lots of damage to their own system, of their own accord. But this attack will succeed if the user simply clicks the wrong button, and the fact is that they will.

Re:No word?

[pudge]

How is click cancel when you see this dialog any more complicated then "don't open unknown email attachments"?

You were talking about how the user would then go and find the application to open manually. Even if you had left it at only this point, it is more complicated because you are forced to make a choice, one you don't understand the meaning or ramifications of. With email attachments, you merely don't have to take a particular action.

But I'm at a loss to what you can do to prevent it?

As I've said many times: DO NOT register apps until they are first explicitly launched. This dialog would not come up because the action would not be possible.

There are untold numbers of things you can do to people who don't learn to distrust software delivered to them without their express cooperation.

Yet another Excluded Middle fallacy. There are levels, and I am simply saying you should not rely on an on-the-spot user choice when it comes to a potential remote attack. This should be a bottom-line rule. What if Mac OS X were to pop up a dialog, saying, "An incoming packet on port 23 is detected, but telnetd is not currently running. Shall I start telnetd to allow the connection to go through?" That's what this is basically doing.

Re:No word?

[Lars T.]

What happened to the Apple HIG mantra "Press Enter and the safe option will be activated"?

Re:No word?

[baur]

Yet another Excluded Middle fallacy

You know, you keep saying that, but it sounds like you are doing the same thing. You seem to be claiming that no "typical" users are smart enough to figure out what's going on. There are not just smart and dumb users, there is a range. Designing things like this means striking a balanace between security and convience. There are no hard-and-fast rules about it.

The main reason I responded though was just to complain about your analogy. It doesn't fit. The remote exploit that this is all about is not completely automatic. It requires the user to browse the internet to a malicious site. Your example describes a more dangerous situation where a users machine is at risk randomly and needs to only be connected for it to happen.

My only reason for mentioning this is that, since the user is already activly involved in the process, its not a great leap to have some instructions on the site like: "A new volume should show up on your computer, please double click the file in there to see the cool cartoon."

I know what you're going to say, this is an "Excluded Middle Fallacy." No more than what you've proposed. What I'm trying to say (and I suspect a few others) is that you have to trust the user to do the right thing *at some point* - although I'll grant its debatable at what point that occurs. There is some anecdotal evidence that dialogs are not always read and understood, but this still turns an automated exploit into one that requires an extra step of user interaction. This is not a dialog that users will see frequently, and so it isn't one that they will become jaded by. I understand your position, but - for me - it restricts features a little too much. There are cases where you would want to say "Ok" to this dialog (like a help:// tag, for example - I would be very annoyed if I had to go an find the help app just to launch it once before it could be used). There are other situations as well.

As I've said many times: DO NOT register apps until they are first explicitly launched.

This sounds good on the surface, but think about it - do you want to have to explicity lauch every helper app before it gets used automatically? (Although its not quite true, let's assume this afects pre-installed apps as well.) Want to unstuff and app? Sorry, you need to hand launch Stuffit Expander once first. Want to use the Citrix client to connect to a remote server? Sorry, gotta launch the client once (never mind that it makes no sense to do so without a connection file).

I don't want to deal with that, because I don't like my computer getting in the way of what I'm doing - and I don't feel that its a great compromise of security to have a dialog box appear (although I do think the default should be cancel).

Change in text maybe?

[wedding]

I like the idea, but couldn't the wording of the alert be simpler?

Why not ask "The document you're opening is trying to open and run _____. If you don't want to do this, click CANCEL."

The message makes sense to a geek, but I'm with an earlier poster, many users will just click OK out of confusion.

Re:Change in text maybe?

[cheide]

The goal here is to get the user to think "Hey, I wasn't expecting this! Hmmm, if I wasn't expecting it, then I better cancel it..." People tend to become complacent and click Yes/OK to any old 'plain' dialog that comes along, though, so wording that has a bit of a warning tone to it and an attention-grabbing graphic might get them to take notice.

Of course then the danger is that they might be too cautious and cancel it when they should have let it run, and then their app or web page doesn't work, but at least that's a safer failure mode.

Re:Change in text maybe?

[PierceLabs]

True, but the ocurrence of that is currently pretty rare since most poeple never really encountered the URI exploit in the wild and almost no real application would require that functionality to be exposed to the user in that manner.

I think this fix is reasonable in that it won't be popping up all the time and when it finally does - it will look out of place and the default behavior should be to cancel (not allow) the operation to continue.

Re:Change in text maybe?

[justMichael]

The message makes sense to a geek, but I'm with an earlier poster, many users will just click OK out of confusion.

While this is true in Windows, the dialogs are worded very poorly and usually only have OK CANCEL. The dialogs in OS X are usually worded in such a way as to make sense and the buttons usually have words on them directly related to what they do.

Even in this example, Cancel Open, so you know even without reading the dialog that one button is going to open something and the other is going to cancel.

Where as OK CANCEL is completely reliant on someone reading the dialog (not normally going to happen) or click OK and see what happens.

The action you are trying to perform will destroy data and we have stopped it, do you wish to allow it to continue? OK CANCEL

The action you are trying to perform will destroy data, do you want us to stop this from happening? OK CANCEL

Re:Doesn't work?

[FredFnord]

> test 2 - "idisk" mounts, but it brings up the new dialog.

That's the fixed part.

> test 4 - terminal launches, and attempts to connect to a remote site -
> appears that if it were a malicious site, it would have worked.

A malicious... telnet... site? Er, whee, lookit the pretty birdies.

The telnet: URL handler is *supposed* to open a telnet connection. It doesn't install any code, it doesn't download anything, it doesn't even execute any commands. It just opens a telnet connection.

The issue that is fixed here is having a disk image mount and create a new URI handler, and then a redirect on your web browser launching the application using the new handler.

This doesn't affect telnet handlers, which are already registered and don't run anything on random mounted disk images.

It doesn't affect helpviewer, which has already been patched and fixed. That is, helpviewer can no longer run arbitrary scripts, so the fact that the disk image mounted doesn't make a damn bit of difference.

Basically, don't post warnings about things you have no clue about.

-fred

Re:Usability Growing Pains

[mbbac]

It also doesn't say 'OK' or 'Cancel.' Like most good Mac dialogs, it uses action verbs. In this case the options are 'Open' or 'Cancel.'