"LaunchServices automatically registers applications, which could be used to cause the system to run unexpected applications.
|Another Open Letter to Apple|
This patch will create a false sense of security without addressing the basic design flaw. All an attacker needs to do is find an exploit in a frequently used component, one that would have already been launched through LaunchServices for most users (such as help:), and they will be able to launch an attack on almost as many systems as they would have without this patch.
"Once an application has been opened, this message will not appear again for that particular application."
Since most users use "help" some time or another, this patch would not have provided any protection from the recent exploit.
"Applications included with your computer are considered "trusted" and will not trigger the warning panel."
Since "help" is included with the computer, this patch would not have provided any protection from the recent exploit.
The proper fix is to either pass to LaunchServices a request for "web applications only", or to have a separate "WebServices" API that applications (ike browsers or mail readers) can use for resolving links in untrusted documents.
That way, since there is no reason for an untrusted document to open a help viewer, the "help:" protocol would not be included in the "web applications" list or provided by the "WebServices" API. This would have prevented the recent exploit, and would provide real protection in the future AND it would do it without inconveniencing users.
|And it has been reported that it breaks Paranoid Android:|
Some people have been reporting problems when using paranoid android but i just turned it off in the APE manager before i restarted the computer.
Alas, Jason may be a while fixing it... on Unsanity's blog:
As far as I can tell based on a quick read of the ReadMe and the associated technote, this resolves all of the issues that Paranoid Android was created to protect against.
Unfortunately, it doesn't. I recommend relying on Paranoid Android and holding off on this patch until it's compatible.
|Update Jan 2005|
I had this GO screen saver running. I hit a key to exit the saver. This key tells the saver to run "goban", so it kicks off goban before exiting. That would normally be OK, but I had never run "goban" before.
You can see where this is going...
LaunchServices pops up a dialog asking if it's OK to run "goban".
UNDER THE SCREEN SAVER.
Which of course is locked up until this dialog is answered.
Thank god for ssh and kill.
Urgent message to Apple:If a local application that is not honoring a request by an alien object wants to run another application, it is always just as safe to let it do so as to let the original application run in the first place. You don't stop people robbing banks by asking everyone walking out of the bank "did you rob the bank today?"...
That's what Microsoft does. Apple is supposed To be smarter.
A couple of people have accused me of wanting to cripple LaunchServices, or to make the system less user-friendly.
On the contrary, I want to prevent Apple from heading down the road that Microsoft is on where they have had to remove functionality from programs and make the system less user-friendly over time because they're trying to use one set of bindings for two quite different purposes. Applications in Mac OS X routinely use LaunchServices locally to launch the help viewer, to launch their own helper applications and plugins. If you install Paranoid Android and use it for a while you'll find it popping up at the most unexpected times. Every one of those places is a potential situation where Apple will have to choose between breaking an application or making the system less user friendly... and improving security.
If, instead, only those services that make sense in webpages and email are put in the "Web" side of LaunchServices, then without making the system any less user-friendly or reducing the capabilities of LaunchServices anywhere you instantly reduce the security threat from "all protocols" to "all protocols that are allowed in web pages".
An anonymous response on MacUpdate:
I recommend separating trusted users from untrusted users, and
keeping all untrusted users away from the computer.
So what do you do when someone wants to link their help file to a
remote copy that they can update on the fly? Networked resources
are going to be used. If there is a security vulnerability in help,
fix it in help. The underlying structure is sound.
I recommend separating trusted users from untrusted users, and keeping all untrusted users away from the computer.
So what do you do when someone wants to link their help file to a remote copy that they can update on the fly? Networked resources are going to be used. If there is a security vulnerability in help, fix it in help. The underlying structure is sound.
I think you're thinking about this backwards. I'm not suggesting that the protocol list be limited based on the destination of the link, but that it be limited based on the source of the link. If the application has a URL in its defaults database or embedded in its code, it would normally be expected to use the regular LaunchServices database. The WebServices database is the one that would be used to resolve URLs inside third-party documents (eg, web pages, email messages), not those built into and maintained by the application.
So an application would be able to launch Help Viewer with a remote document directly, it just wouldn't allow some third party to use it to launch a "help:" URL it ran across in another document.
As an additional benefit, a vendor could provide a "safe" version of their application with features like local scripting removed, and put that in the WebServices database. That way when you opened a document from Finder you'd end up in MyFirstEditor (or whatever), but when you opened it from a web page you'd end up in MyFirstEditorViewer.
And finally, if the help viewer is really safe now, and Apple is absolutely sure they have it right this time then they could add "help:" into WebServices. I didn't say you shouldn't ever add new protocols into that side of the database... just that it shouldn't include everything that LaunchServices curently handles by default.
 Remember, Microsoft's help viewer just got hit by a cross zone attack (their equivalent of these URL protocol attacks in OS X) this year, and they've been patching holes app by app for almost a decade.
|Lynx-enhanced by <peter at taronga.com> (Peter da Silva)|