Unsanity is just a little bit unsane as of late. After it was discovered that the help: URI handler could trigger scripts mounted on disks with the disk: URI handler, they went and claimed a security problem with automatic registration of URI handlers via Launch Services.
The idea is that a program has a property list file that tells Launch Services which files it can open and which URI handlers it supports. This enables one to, for example, install Safari and have it handle http: requests and open .html files as well, without configuration from the user. This is pretty standard stuff. So the “exploit” is to install a program (using disk: as before) and then call the URI handler from a META tag refresh on a web page.
This is not a bug or security problem with Launch Services. This is a bug with DiskImageMounter (the program that transparently mounts disk images for the Finder, and is the default handler of the disk: and disks: protocols). The same thing needs to happen for this program as happened for Help Viewer: if the calling program is not itself (or in this case, Finder) then either error out or ask for permission.Launch Services is behaving exactly as designed; the programs it is calling are the ones that are not doing basic security checks. Calling Launch Services insecure for this would be like calling the Finder insecure because it opens Word files that can have viruses inside. The job of LS is to connect the data with the right program. It’s up to the program to do the right thing with the data.
That said, the following programs need a dialog to confirm the use of the associated protocols when called from outside the expected program (such as Safari calling most any of them):
- Finder: AFP, FTP, SMB, NFS
- DiskImageMounter: DISK, DISKS
- Terminal: TELNET
The following already do the right thing:
- Script Editor: APPLESCRIPT (just loads, does not run)
- iCal: ICAL, WEBCAL (prompts “Do you want to add…”)
- Terminal: X-MAN-PAGE (try as I may, I could not pass arguments to the
manprogram, even URL encoded; this does not suffer the TELNET bug) - Help Viewer: HELP (as of the update, only Help Viewer can use the RunScript command)
I don’t think that you did understand what Unsanity is trying to tell us. Actually what they say is that if an application is downloaded that registers any made up URL identifier, e.g. evil:// that application is opened when the URL evil://anything is called.
This makes that the just downloaded app is executed, and that could contain dangerous code.
Please reread their explanation before calling them insane.
Kool: Please re-read my entry on this. The automatic registration of a protocol is not a security problem, it’s a feature (no, really). The problem is that the system can mount disks or decompress archives without the user’s permission (thus triggering the auto-registration). The problem is not with Launch Services but with DiskImageMounter.
I am well aware of what parts of this are the problem. I’ve read their hypothesis. It’s wrong.
So, you have just pointed out other problem areas. The question is, when are they going to fix them?
What about real CDs? The fact that simply mounting a disk can register a URI handler, without my permission and without any feedback, represents a huge risk. I’m at the mercy of anyone who has ever produced a CD that I might insert. That includes software installers, catalogs on disk, audio CDs, DVDs…and lord help the poor service bureau that deals with homemade CDs all day every day!
At the very least, Launch Services should be configurable to prompt before registering any URI handler that is not on the boot volume.
Once again, this is not an issue with Launch Services. You are right in that it will register those files and protocols of programs on removable media, but what you neglect to understand is that this behavior has been with us since System 6 and it is how the Macintosh works and not a security problem. If you insert a CD into your computer that you don’t trust then that’s your problem. The computer cannot, and should not even attempt to try to, prevent a user from destroying himself with untrusted software.
The issue at hand, and let’s get this clear because people are deviating, is that there was a problem with a webpage starting a program without someone’s permission. That is the fault of DiskImageMounter. There is no Launch Services “bug” as it’s working exactly as designed. In the case of a CD, if the user inserted an unknown and untrusted CD and the user opened an unknown and untrusted document that called an unknown and untrusted URL then SURPRISE you might get an unknown and untrusted program running on your machine. I think anyone expecting less is simply foolish. On the other side, if you are concerned that a URI handler could be specified by inserting and removing a CD remember that for a URI handler to work the program it’s registered to must be present on the machine. This is not the case with removable media. If you insert and remove a CD (and open the folder containing the malware program) and then later on go to an untrusted site that calls that protocol the computer will say it doesn’t know what to do with it because the program is gone. This is only ever useful if there is a way of keeping the program available on the machine. In other words you have to have either automatic execution of a document or you have to have a way of delivering a file without a person’s knowledge.
And then we’re back to the
disk:vulnerability. That’s the only one there is left, and for those reasons. Launch Services is not a problem and never was. In fact, it’s due to the design of Launch Services that you can get around the bug in DiskImageMounter!!!<rant&rt; If you don’t understand the design of the operating system stop critiquing it as you are not qualified to understand the design decisions that took place. If you are a user of the operating system, keep doing that. Let the rest of us work on explaining and demonstrating the problems and letting Apple fix what it needs to. I’m sick and tired of amateurs coming into this very technical discussion thinking that by reading some damned MacNN thread they’re fucking experts on the whole fucking issue. The fact is the great majority of people hearing about this know fuck-all about the situation and are spreading FUD with every underinformed breath. What I’m trying to do on this site is explain what the real problem is rather than listening to the teenagers writing foolish programs that solve the wrong problem. </rant&rt; —>
CP, I am a total Code Idiot. I thought that trained mice following trails of powdered cheese executed all the computer stuff. I didn’t read this on MacNN, I thought it myself. Now you tell me that the cheese is not powdered? And it will only gum up my Mac if I shove it in the CD tray? Is there no hope that I can be an expert on something complicated by reading magazine articles.
Rogre