Apple Addresses URI Handler Issues 106
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.
No word? (Score:5, Insightful)
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 [apple.com]
http://www.info.apple.com/kbnum/n25785 [apple.com]
You can verify that these issues are fixed by using the following test site: http://test.doit.wisc.edu/ [wisc.edu]
Re:No word? (Score:5, Funny)
You think much more highly of the average user than I do.
Re:No word? (Score:1)
Re:No word? (Score:5, Insightful)
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? (Score:3, Interesting)
You're committing the Excluded Middle fallacy here. There are degrees. In this case, we are talking about a remote attacker doing things without user interaction, except to click on a dialog box *they don't understand*. They only have two options, and
Re:No word? (Score:5, Insightful)
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? (Score:2, Insightful)
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 th
Re:No word? (Score:2)
Re:No word? (Score:2)
Re:No word? (Score:2)
Re:No word? (Score:2)
I ate there once. Great place, great food, great service. I left a huge tip,
Re:No word? (Score:2)
No. This is all over your head, isn't it? The problem is that apps are automatically registered, and can be run *for the very first time* without *explicitly* running the application (such as, by opening a file of a certain type, or using a URI handler). "For the first time" is the key here: no app should be automatically registered, and should require explicit execution before it is registered. After this initial execution, everything
Re:No word? (Score:2)
Re:No word? (Score:2)
Re:No word? (Score:2)
Go back to the same web page, if the dialog is gone, it was legitimate, if it still present when they go back then it is malware. Easy. Even the most unsophisticated user can follow those easy instructions. They are not going to get bombarded with this dialog. It is going to be a rare event for the average user.
I
Re:No word? (Score:2)
They won't hear you tell them, and they won't remember you told them. Even if it is in the dialog box itself -- which it is not -- it won't help.
Even the most unsophisticated user can follow those easy instructions.
No, they cannot.
It is going to be a rare event for the average user.
Which only hurts your argument, as infrequency dulls the memory. There is no chance, for some of them, that they will recognize the dialog box for what
Re:No word? (Score:2)
And you are probably correct that some people will never learn and will eventually get hit by this potential problem. But I'm at a loss to what you can do to prevent it? Any suggestions for the very weak minded who can't follow even the simplest of advice?
There are untold numbers of things you can do to people who don't learn to distrust software del
Re:No word? (Score:3, Insightful)
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 sa
Re:No word? (Score:2, Insightful)
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 ex
Re:No word? (Score:2)
But I am not.
You seem to be claiming that no "typical" users are smart enough to figure out what's going on.
I claimed no such thing, sorry. I never said or implied anything similar to that. What I said is not that NO typical users will, but that SOME will not.
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.
Re:No word? (Score:2)
Neither have I but I am sure (because it's Mac OS X) it goes a lot farther to empower and help the user understand the implications of their actions than the 'Always Trust Content from Gator Corp.' dialog you get with Internet Exploder.
Re:No word? (Score:3)
Yes, it is in one of the links [apple.com] I put in the story.
Neither have I but I am sure (because it's Mac OS X) it goes a lot farther to empower and help the user understand the implications of their actions than the 'Always Trust Content from Gator Corp.' dialog you get with Internet Exploder./em?
It doesn't. It says "if you were not expecting this application to open, click Cancel." I am not arguing about this dialog specifically, but the fac
Re:No word? (Score:5, Insightful)
Re:No word? (Score:5, Funny)
Everyone knows that we're taller, more attractive, more aromatically enticing, (prone to verbose grammer), and more intelligent than the average computer user.
Re:No word? (Score:1)
Cool.
Troc.
Re:No word? (Score:2)
It's my impression Apple got at the crux of the issue: indirectly running code you know nothing about. If you've run the code before and are still here...
You can argue till the end of the year whether the wording is appropriate, or how many nimrods will get 0wned anyway, but the technical side of it is very well I think: the essence of the 'hole' was that any protocol could be made up. This does a good job of watching out.
Re:No word? (Score:2)
Only if you understand the warning message (or have access to someone who does, who can tell you what to do). If you don't, then all it's done is reduce your chances of being exploited by 50%.
Re:No word? (Score:2)
Re:No word? (Score:5, Insightful)
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? (Score:3, Insightful)
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
Re:No word? (Score:2)
This might mean something to experienced, knowledgable users. The rest of them are just going to click "Yes".
Since you can't do that without an Admin password, any legitimate Application already has to be installed with a users consent.
Since the default group for the first user is admin, most users will be running as an admin user and can happily copy stuff into /Applications with
Re: (Score:3, Informative)
Re:No word? (Score:3, Funny)
And here I thought that only trademark lawyers were that easily confused...
Re:No word? (Score:2)
A lot is dependent on the system becoming aware of schemes and file types. I don't take it as a given that a new file type will be recognised simply because I've unzipped a package off the net with its handler inside. I do expect
Re: (Score:2)
Re:No word? (Score:2)
Re:No word? (Score:2)
I can argue vehementally, without a doubt, that this is totally, utterly incorrect for most users. The average user can barely tell what an "application" is, let alone know what to click.
It isn't clear in the screenshots (I'm going to test this on my iBook) whether or not Cancel is the de
Re:No word? (Score:2)
http://docs.info.apple.com/article.html?artnum= 2 57
No word is given? (Score:5, Informative)
Basically, it notes that the app is being started for the first time, and it says that unless you expected to see that app come up in response to whatever you just did, kill it by pressing 'Cancel.'
I think this is a pretty good way of handling the situation. They could have left the hole unplugged, or simply disabled the functionality in general. The dialog box strikes me as a good compromise.
However, I do think a little more info might be nice, like how long ago the app was installed, etc. Might make it harder for a new app to masquerade under the name of an old app.
Sure there is. Well, sorta. (Score:3, Informative)
Usability Growing Pains (Score:2, Interesting)
Re:Usability Growing Pains (Score:5, Interesting)
Who knows, it might be a good experiment.
Re:Usability Growing Pains (Score:5, Insightful)
Re:Usability Growing Pains (Score:2, Interesting)
Does this solve the problem completely? Of course not, but this is a fairly good solution that covers most cases, makes the majority of people more secure and doesn't keep me from usi
Re:Usability Growing Pains (Score:3, Informative)
OS for people other than the tech savy? I think Apple's been doing that for a looooong time. However, making an OS that doesn't suck for the techies yet remains usable for the dummies is another story.
All in all though I think they've done a fine job. My mom got an iBook about 8 months ago and She hasn't called me with questions for the last 6 months. When she had Windows she called me frequently... for years...
Re:Usability Growing Pains (Score:3, Informative)
I welcome Apple to the problems of making an OS for people other than the tech savy.
Um, yes...because...goodness knows...that Apple, um...hasn't been doing that for the past twenty years! What other company could you possibly be comparing them to with a statement like that?
Re:Usability Growing Pains (Score:1)
Re:Usability Growing Pains (Score:1)
Re:Usability Growing Pains (Score:2)
It is possible to prevent this entire class of attacks while retaining user-friendliness.
The way you do this is realise that the Internet is a hostile environment, and that the services and resources appropriate for local applications are NOT always the right thing to open when requested by a remote and untrusted web page. Some protocols simply make no sense for remote requests (mounting a disk, for example, opens up a whole class of potential attacks), and in other cases you
Re:Usability Growing Pains (Score:2)
Microsoft have never tried to make their operating systems 'user friendly enough for the average user'. There is no such thing in the Microsoft camp. Microsoft have equipped their software with 'showroom flash', fully aware of the fact that most users dating back to 1995 have not had a clue about inherent dangers while surfing like that online.
Further, Microsoft's typical answer to JavaScript was a scripting system that did not respect security as JavaScr
How will they know? (Score:5, Funny)
Yes, I was just about to hit SubmitStory, and yes, I'm still bitter. ;P
Re:How will they know? (Score:1)
1) go to a webpage (and only that!)
2) and suddenly an application launches,
without you doing anything, you know you don't want it to open!
I assume Cancel is the default button?
Re:How will they know? (Score:5, Funny)
Change in text maybe? (Score:5, Insightful)
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? (Score:2, Insightful)
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
Re:Change in text maybe? (Score:4, Insightful)
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? (Score:5, Insightful)
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.
Doesn't break Paranoid Android (Score:5, Funny)
What that means, I don't know. I'm an Apple user. Hold me.
Doesn't work? (Score:4, Informative)
4 tests [slashdot.org]
The first one does not execute, but no dialouge is presented.
The second one executes.
The third does not execute, but does launch help viewer, no dialouge
The fourth does not mount or execute on the volume, but does launch a terminal trying to access the volume.
The only reason I can think of why this didn't take may be because I have PA installed but diabled, and it may be interfering with the patch.
Is anyone else having this issue?
Re:Doesn't work? (Score:5, Informative)
It appears to be all fixed, as some of the methods to install the exploits still work, but the exploits themselves do not run. I wonder if anyone will find a way around the fixes.
Re:Doesn't work? (Score:2)
Re:Doesn't work? (Score:2)
Re:Doesn't work? (Score:2)
Re:Doesn't work? (Score:2)
ssh: a -F
[Process exited - exit code 255]
More information (Score:2)
the first does not execute and no dialouge is presented
The second does not execute, it mounts the server and brings up the dialouge.
The third does not execute but does launch teh help viewer
The forth does not execute but launches the terminal as per the thread in the replies above this one.
Re:Doesn't work? (Score:1)
test 1 - nothing seems to happen - no autostart, no dialog... no nothing.
test 2 - "idisk" mounts, but it brings up the new dialog.
test 3 - help viewer launched and remote disk "idisk" mounted. Then it sat there. If there would have been folder actions accosicated with this share - i'm sure i would have been boned.
test 4 - terminal launches, and attempts to connect to a remote site - appears that if it were a malicious site, it would have worked.
i have nothing from insanity
Re:Doesn't work? (Score:5, Insightful)
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
Malicious telnet: how the exploit works. (Score:2)
telnet::-nmbox will create a trace file of zero length named "mbox". If there was already a file by the same name then the pre-existing file will be silently deleted.
The same exploit could zero out any file with a predictable path name to which the user has write access.
That's what test 4 is about. It's a
Re:Malicious telnet: how the exploit works. (Score:2, Informative)
Re:Malicious telnet: how the exploit works. (Score:1)
Nope. Tried it just now - all it does is open Terminal.app; no other effects that I can see.
It was... (Score:2)
-fred
Re:Doesn't work? (Score:2)
The first one does nothing.
The second one mounts the volume "idink" and presents me with the new dialogue.
The third doesn't mount a volume, but it launches the Help Viewer.
The fourth doesn't mount a volume, but it pops up Terminal.app with the ssh command mentioned earlier.
That's a nice 0 for 4, but given that I only got the dialogue on one, so I tried thre
Re:Doesn't work? (Score:3, Informative)
this exploit is not fixed.
Yes it is.
If you ran the test exploits before installing the update, then the applications that they run are already "trusted" in the sense that they were already on your computer as registered handlers for those URI types, so the dialog does not appear (if the dialog appeared for every preexisting application on your computer, then its meaning would be diluted to the point of uselessness). Since these proof-of -concept applications are harmless, there's nothing to worry abou
Re:Doesn't work? (Score:2)
Since the exploit was found in existing code that almost any user would already have run, how precisely would this have provided any protection?
Basically, this dialog provides nothing but a false sense of security.
The real fix is to have a separate list of URIs that browsers and other programs using untrusted software will use. Not only are many applications unnecessari
Re:Doesn't work? (Score:4, Informative)
Dumb People... (Score:5, Interesting)
What I do not understand is how you can completely eliminate danger from ill-formed people. The fact of the matter is that people are responsible for using computers. We can either have completely dumbed-down OS's (namely, companies such as Apple and M$ take complete responsibility for every sort of sescutiry isssue and to do so ensure they strict limit our use of their products to help mitigate their risk to such a godly -- and equally inane -- level of responsibility) or we accept the fact that the end-users have some responsibility, too. So how should the user know whether to accept or deny...read a book, google it up, or any other of a thousand ways people have spent millenia educating themselves...
Granted, the dialog that Apple has implemented could include some more information, but it is certainly in the right direction. As I am away from a Mac for a week, I am not positive how the new system works. I am not sure if you can say "Always permit this URI..." or if permission is on a per session basis. If the latter that might become annoying...and it might be nice to say "Forever Accept/Deny" in those cases where I feel confident that I can/should do that. Having said that, the one thing that I'd like to see is a list of those apps/URIs I have granted/stripped permission to/from so I have better management over the system....esp. after I FUBAR and grant permission to EvilWare!
ill-formed people (Score:4, Funny)
Re:Dumb People... (Score:2)
As proof of the ineffectiveness, if this had been in place when the "help:" hole was discovered, it wouldn't have triggered: it's Apple's own tool!
I am not installing this update, because it interferes with Paranoid Android, which actually DOE
Dang it! (Score:4, Funny)
arg! (Score:3)
Software Update now claims I'm all up to date, but now I'm not so sure.
Re:arg! (Score:5, Informative)
In the future, instead of clicking on the button, use the menu "Update > Download Only" for your updates. It will download the update and keep it so that if the machine locks up or the powergoes out you can re-install from the saved
NarratorDan
sshLogin needs to be reinstalled (Score:2, Informative)
Re:sshLogin needs to be reinstalled (Score:1, Informative)
Don't be ridiculous (Score:3, Interesting)
Trust me. If Slashdot was trying to hide something, they would post it on the front page, in foot-high green letters. Using the 'flash' tag. By accident.
Besides, I frankly think that none of those deserved to be on the main page, including this last one. Basically, they're of interest if you're a Mac user, a Mac admirer, or a Mac basher, and all three of those types already read the apple.slashdot.org section.
And likewise, i
Re:Don't be ridiculous (Score:1, Flamebait)
Re:Don't be ridiculous (Score:2)
Re:Don't be ridiculous (Score:2)
Um...?
Did you read my post before rebutting it? (Score:2)
Oh yes... yes... agree with me *harder*!
From my original post:
Re:Don't be ridiculous (Score:2)
Keep looking.
-fred