[Developer]

Originally posted by Hugin777:
I have updated my example exploit page so it's now possible to test Application Code Hijacking.

I didn't succeed in hijacking Mail or HelpViewer, possibly because of the "LSIsAppleDefaultForScheme". I was able to hijack iTunes (itms), though; possibly because Apple used "LSIsAppleDefaultForType" here instead (a misspelling?).

Did you try to be Apple default for the hijacking app?

I have a different theory why it didn't work. Help and Mail are still assigned via Internet Config (now more or less deprecated). The iTunes Music Store is newer and the itms: protocol is registered via the modern LaunchServices only. I would guess that's why you could hijack the protocol with a "more recent version of iTunes".

You could maybe try with addressbook: (which isn't in Internet Config for me) or with the several StuffIt assigned to protocols (which probably are not assigned via LaunchServices since StuffIt doesn't have them in the Info.plist and so they're not Apple default).

Decisively you can only answer it by looking at the LaunchServices code (and that of Internet Config since the two collaborate in some way), so this is something for Apple to investigate.

[Hugin777]

Originally posted by das:
For convenience, I've created a new page at http://test.doit.wisc.edu/ that includes all of the known methods for exploiting this, including afp, ftp, disk, and compressed files, as well as automated versions of each.

A nice page. Only protocol that's missing is disks:, but I'm not sure how that works anyway.

It could easily be expanded to include the three types of vulnerabilities as well (in your step 2). But that depends on the purpose of the page.

- I must admit that I would prefer just the dialog box and not the owned.txt in my home folder, though...

[Hugin777]

Originally posted by Developer:
Did you try to be Apple default for the hijacking app?

[..]

Decisively you can only answer it by looking at the LaunchServices code (and that of Internet Config since the two collaborate in some way), so this is something for Apple to investigate.

Yes I did. And you are right; Apple has to dig into this, not us. We only have to check whether we are safe

[sniffer]

So what does this imply? PA needs to become limited again to the obvious safe protocol handlers; http, https, mailto, and everything else should be optional? At least I would be in favor for such solution as I rarely need anything outside the mentioned all-standard protocol handlers while browsing. Perhaps ftp is an exception, but if it could be added manually after reassigned to an app other than Finder, then it wouldn't be an issue IMO.

BTW: As I am in to the topic, perhaps PA dialog box could have an additional button, like allow in this browser session. And everything else should be permanent change able as an option in System Preferences for the more advanced users.

Just my two kroner.

[das]

Originally posted by Hugin777:
A nice page. Only protocol that's missing is disks:, but I'm not sure how that works anyway.

It could easily be expanded to include the three types of vulnerabilities as well (in your step 2). But that depends on the purpose of the page.

- I must admit that I would prefer just the dialog box and not the owned.txt in my home folder, though...

'disks' should work as 'disk', but via https (port 443), which I currently don't have enabled.

Also, which other vulnerabilities should be included in step 2? Are you talking about application code hijacking?

Lastly, I'm just reusing Unsanity's example application, which writes the owned.txt file...

[kangoo_boo]

I'm sure you guys would be interested about yet another exploit for URIs.
It is not known. It uses OpenSSH and URI's, but it's not really an URI vulnerability. Basically, that could work on Linux too.
It does not abuse helpers, and it breaks Apple's Security Update for which didn't allowed to insert file paths in the URL's.

Oh yeah and, as I read the thread, hmm you do not need to all copy my demos, one is enought, more is lame (especially when you claim it's your own)

here it is
http://www.insecure.ws/article.php?s...00405222251133

have fun, and remember to protect yourself

edit: pratically, you can do ssh://fakehost -o'ProxyCommand yourcommand' in the url without having to know the path. It's written on the advisory in italic, knowing the path is not always required. Depends on OS's etc. I used a path to demonstrate the fact that Apple's protection for path, which was just introduced, was just broken too.

[alcatholic]

Originally posted by kangoo_boo:
I'm sure you guys would be interested about yet another exploit for URIs.
It is not known. It uses OpenSSH and URI's, but it's not really an URI vulnerability. Basically, that could would on Linux too.
It does not abuse helpers, and it breaks Apple's Security Update for which didn't allowed to insert file paths in the URL's.

here it is
http://www.insecure.ws/article.php?s...00405222251133

have fun, and remember to protect yourself

Can someone translate?

It sounds like we just have to add ssh: to the blocked list of protocols for the same reason we needed to block telnet: and help: when their respective applications ran commands from url's; you know before Apple fixed the Apple telnet and Helpviewer apps to not accept commands from urls. Actually, is the Panther telnet app fixed?

Anyway, it doesn't seem fundamentally new except that the app is not Apple's but OpenSSH, AFAICT. Am I off?

[theolein]

It also requires a known path (i.e. the disk:// or disds:// hole), but can also be dangerous on its own with port forwarding (forwarding localhost and some port off somewhere). I somehow think Apple is going to have to totally revamp launch services.

[alphasubzero949]

Wow, the rabbit hole just keeps getting deeper.

[alcatholic]

Originally posted by sniffer:
So what does this imply? PA needs to become limited again to the obvious safe protocol handlers; http, https, mailto, and everything else should be optional? At least I would be in favor for such solution as I rarely need anything outside the mentioned all-standard protocol handlers while browsing. Perhaps ftp is an exception, but if it could be added manually after reassigned to an app other than Finder, then it wouldn't be an issue IMO.

BTW: As I am in to the topic, perhaps PA dialog box could have an additional button, like allow in this browser session. And everything else should be permanent change able as an option in System Preferences for the more advanced users.

Just my two kroner.

But what apps can you permanently trust with untrusted data such as a URL?

Here is Peter de Silva's argument about this:
http://scarydevil.com/~peter/io/osx-security.html

My attempt to learn by summarizing:
URL's are untrusted data and you should only control apps via URL if the apps can handle untrusted data, ie apps that can do no harm no matter how evil the data. Browsers should be a trusted app with evil data, if it wouldn't pass that evil data to helper programs that can't be trusted with untrusted data. So, e.g. Browser should never give Helpviewer app "runscript:" commands from a url. Browser could give Helpviewer app "show this page" type commands because HelpViewer can handle that kind of data in untrusted form.

However, with app hijacking, it almost seems you cannot even trust a URL to LAUNCH any app...that came from an untrusted source, i.e. not located in your home directory or whatever.

So, maybe, you can let LaunchServices cache everything, but know that URL's are not trusted data, and so they should not launch apps that come from/located in untrusted space.

[Developer]

Originally posted by alcatholic:
So, maybe, you can let LaunchServices cache everything, but know that URL's are not trusted data, and so they should not launch apps that come from/located in untrusted space.

I don't know if this would work, but it's not too far fetched: if you download a zipped application it is decompressed into the Desktop and could be registered by LaunchServices. That's trusted space. Or a user dedicated download folder is trusted space.

I think ultimately it boils down to what I've said in another thread:

http://forums.macnn.com/showthread.p...26#post1924111

We need digitally signed applications. The system ships with trusted vendors by default (Apple, Microsoft, Adobe, and a few others Apple knows well), and if a program is about to run of another vendor I get a warning and be able to clear that vendor or reject it.

After Tiger Apple has two years time to implement something like that and the problem with Trojans and stuff is solved for good.

[alcatholic]

Originally posted by Diggory Laycock:
Smeger - How about an addition to PA that does a little more detective work - when it catches a url - it could call LSGetApplicationForURL to display to the user which application is registered to launch.

You could have a combination whitelist - e.g. ftp is safe for any app that is not the Finder - mailto: is safe for any app. etc...

If Peter de Silva's argument and my post above hold water, it may be enough for PA to tell us what application a URL will launch and where it is located. And then not allow an app from an untrusted space to launch via URL. Launch services can still cache as before.

In other words, Ftp: is not safe for "any app other than Finder" because apps can be spoofed. So you need to know the name of the app that will launch and whether the app is in a trusted space, i.e. Applications folder, or untrusted space, i.e. some freaky mounted volume you didn't know existed.

I believe Charles S argued close to this when he suggested LaunchServices should not cache from mounted volumes. Instead URL's should not launch from mounted volumes.

IMHO, the beauty is that you can still cache if it is useful, and you can still launch from an untrusted space if the "data" that launches it can be trusted, i.e. YOUR action by double clicking with your mouse or whatever. Just don't let untrusted URL's launch apps. [wait this is wrong, see next]

Which leaves opening the malware via a document tied to the spoofed creator code, no? So Word is spoofed, downloaded via disk:, and cached. URL isn't trusted to launch it so the bazaro-Word waits until you open a word doc. I think this may be a new vector assuming you can use disk:, ftp:, etc. to download and allow an app hijacking via LaunchServices cache. Of course, a very weak vector because who will allow a drive to sit on their desktop for however long it takes to open a Word doc after visiting a webpage. Still...

I change my mind. I think Charles S was right. LaunchServices can't be trusted to cache from untrusted spaces, e.g. drives mounted via ftp:, disk:, etc. Too many untrustable sources can use LaunchServices to launch malware.

[Hugin777]

Originally posted by kangoo_boo:
I'm sure you guys would be interested about yet another exploit for URIs.
It is not known. It uses OpenSSH and URI's, but it's not really an URI vulnerability. Basically, that could work on Linux too.
It does not abuse helpers, and it breaks Apple's Security Update for which didn't allowed to insert file paths in the URL's.

Oh yeah and, as I read the thread, hmm you do not need to all copy my demos, one is enought, more is lame (especially when you claim it's your own)

here it is
http://www.insecure.ws/article.php?s...00405222251133

have fun, and remember to protect yourself

This seems to be fixed in 10.3.4. I know a guy who has it, and he just get:

ssh: a -F /Volumes/ssh/config: No address associated with nodename
[Process exited - exit code 255]

We all hope that 10.3.4 is released this week, don't we ? (Or, maybe they could include all fixes and release it next week ? Nah, I don't think so)

[sniffer]

A little brainstorming for alternative solutions ..
What about quarantined default download folder, so it gets out of reach for Launch services, running scripts, etc, or something like that .. Perhaps it's possible as a third party addition to PA until Apple is out with an update (that hopefully takes care of everthing)?
Not sure if I like the digital signed idea. I don't like the "Designed for" pop-up in XP, and it doesn't guarantee you from "incompatibility" issues or bugs anyway. Perhaps instead for verification each application should have some sort of an open signature to verify it should be capable of handling insecure documents. I think the open source community might prefer that. That way, we should at least be protected from another unnecessary Help Viewer exploit, and only protocol helpers that are intentionally designed for the task would be added to the list. On top of that limiting to only "/Application" and "../CoreServices" apps, will insure that LaunchServices doesn't fetch & add anything that pops up (literally).

..just some ideas. :)

[alcatholic]

Originally posted by Developer:
I don't know if this would work, but it's not too far fetched: if you download a zipped application it is decompressed into the Desktop and could be registered by LaunchServices. That's trusted space. Or a user dedicated download folder is trusted space.

I think ultimately it boils down to what I've said in another thread:

http://forums.macnn.com/showthread.p...26#post1924111

We need digitally signed applications. The system ships with trusted vendors by default (Apple, Microsoft, Adobe, and a few others Apple knows well), and if a program is about to run of another vendor I get a warning and be able to clear that vendor or reject it.

After Tiger Apple has two years time to implement something like that and the problem with Trojans and stuff is solved for good.

You're right about the ftp. I'm just getting confused after three-four days of this....My whole argument might not have held water, but I'm too tired to figure it out right now. Tomorrow, maybe.



One thing, ftp: can't be allowed at all correct? Even if it brings up Fetch, how is that safer? Once it's downloaded and viewed malware will register with LaunchServices regardless of how it was downloaded?

I'm probably just confused. Time to sleep.

[dan7352]

Originally posted by alcatholic:
But what apps can you permanently trust with untrusted data such as a URL?

Don't fall into the trap of thinking you can filter the parameters passed to an external service to control security. The original Morris worm used a loophole in such a filter as one of it's exploits. When the service and the application are maintained by separate entities they won't be fully aware of the effects changes in one will have on the security implications of the other.

Untrusted data should only be passed to an application or service that has been explicitly installed (registered) to expect that type of data or such applications and services should be run in a sandbox that has full control of the security.

[CharlesS]

Originally posted by sniffer:
A little brainstorming for alternative solutions ..
What about quarantined default download folder, so it gets out of reach for Launch services, running scripts, etc, or something like that .. Perhaps it's possible as a third party addition to PA until Apple is out with an update (that hopefully takes care of everthing)?
Not sure if I like the digital signed idea. I don't like the "Designed for" pop-up in XP, and it doesn't guarantee you from "incompatibility" issues or bugs anyway. Perhaps instead for verification each application should have some sort of an open signature to verify it should be capable of handling insecure documents. I think the open source community might prefer that. That way, we should at least be protected from another unnecessary Help Viewer exploit, and only protocol helpers that are intentionally designed for the task would be added to the list. On top of that limiting to only "/Application" and "../CoreServices" apps, will insure that LaunchServices doesn't fetch & add anything that pops up (literally).

..just some ideas.

Ugh, no thanks! I don't want to have all my applications limited to being in /Applications and /System/Library/CoreServices. We need a way to fix this without sacrificing the things that make the Mac such a nice platform.

[alphasubzero949]

Originally posted by Developer:

We need digitally signed applications. The system ships with trusted vendors by default (Apple, Microsoft, Adobe, and a few others Apple knows well), and if a program is about to run of another vendor I get a warning and be able to clear that vendor or reject it.

Funny, Apple zealots mock Microsoft for conceiving such an idea (in Longhorn), and now someone in the Mac community comes along and embraces it.

Go figure.


As far as my stance, I don't want my OS telling me what app I can have on my computer, malware discussion aside.

[Link]

Agreed. This security stuff is a bunch of BS and digital signing is LAME.

[CharlesS]

Originally posted by Link:
Agreed. This security stuff is a bunch of BS and digital signing is LAME.

This security stuff is not a bunch of BS, although I will agree that digital signing seems like not so good an idea.

[Developer]

Originally posted by alphasubzero949:
As far as my stance, I don't want my OS telling me what app I can have on my computer, malware discussion aside.

I didn't say an OS that tells you what app you can have and what not. I said an OS that tells you who the author of an app is. And sure the OS should still allow you to execute unsigned apps. It just then asks before it does so. Or the user generally trusts unsigned apps, but that shouldn't be a default setting.

Originally posted by CharlesS:
This security stuff is not a bunch of BS, although I will agree that digital signing seems like not so good an idea.

Why shouldn't this be a good idea? I see no disadvantage in a signed application. It just proves that who claims to be the author is really the author. What's wrong with that?

[CharlesS]

Originally posted by Developer:
Why shouldn't this be a good idea? I see no disadvantage in a signed application. It just proves that who claims to be the author is really the author. What's wrong with that?

1. It will be a great disadvantage to shareware and freeware authors (you really think the digital signature service will be free to the developers?)

2. It will not help at all for open-source apps

3. Crackers will crack the public keys (never underestimate these people, they'll do it) and distribute hacks with the digital signature of some reputable vendor, and it'll infect everyone thanks to the false sense of security people will get from the thing being digitally signed.

[Developer]

Originally posted by CharlesS:
1. It will be a great disadvantage to shareware and freeware authors (you really think the digital signature service will be free to the developers?)

E-mail based certificates are available for free or cheap ( see http://www.thawte.com ). Even if a Shareware author doesn't want to go through the trouble of getting a certificate, most of them have one product, so clicking a dialog "Trust this app?" once is the same as the "Trust this vendor?" dialog for vendors with certificates. That's no major disadvantage for share- and freeware authors.

2. It will not help at all for open-source apps

It sure will if they distribute binaries (which most do). If you compile yourself you obviously compile with your own certificate. Certainly Mozilla.org will not give away their certificate, but open source licenses shouldn't require this. A certificate isn't code.

3. Crackers will crack the public keys

I don't think so.

[Developer]

Anyway, now that I actually go to the site I liked to myself:

https://www.thawte.com/core/process?...ype=new-devel2

Apple Developer Certificate

These certificates can be used by Apple developers with a future version of the Apple Mac OS to sign software for electronic distribution.

[Diggory Laycock]

Signed Code is a nice idea - but in practice few people use it - every Symbian app I have ever installed (except Opera) has been unsigned - even though it's built-in and the OS warns you at install if the app is unsigned.

[edit]
WOAH!

Just visited the Thawte link - and it helps prove my point - $200 for a year's cert! ($300 for 2 years)

I personally don't charge for the S/W I write - so it looks like signing is out.

[CharlesS]

Originally posted by Diggory Laycock:
WOAH!

Just visited the Thawte link - and it helps prove my point - $300 for a year's cert!

Hey, I thought it proved my point.

I personally don't charge for the S/W I write - so it looks like signing is out.

Exactly. Warning about non-signed apps will relegate freeware and many shareware writers to second-class citizen status. Since the Mac's shareware community is one of its greatest strengths, this seems like a not so good idea to me.

[sniffer]

Originally posted by CharlesS:
Ugh, no thanks! I don't want to have all my applications limited to being in /Applications and /System/Library/CoreServices. We need a way to fix this without sacrificing the things that make the Mac such a nice platform.

How is that unpractical? I am not saying you can't put applications elsewhere than ..coreservices, and application folder. Just that they shouldn't be automatically picked up as a protocol helper application unless they are where they should. Oh well, perhaps it wouldn't be all Mac like, but I doubt it would've been all that inconvenient either, as most people store their app in the application folder anyway. Just a thought.
And there should be some kind of verification that an app is capable of being trusted with an insecure document, of course. Personally I am as mentioned in favor of an simple,open&free solution that at least doesn't discourage the open source community, and possible less troublesome for the end user which probably will need an app regardless if it's signed or not.

[theolein]

Originally posted by Developer:
Anyway, now that I actually go to the site I liked to myself:

https://www.thawte.com/core/process?...ype=new-devel2

Apple Developer Certificate

These certificates can be used by Apple developers with a future version of the Apple Mac OS to sign software for electronic distribution.

The thing is that you've been on on your signed application trip for a while now, ever since that demonstration mp3 trojan came about, IIRC. One size does not fit all.
1.So we all have to fork over money now if we want to develop an acceptable application for Mac OSX? Why don't we just use Windows, it's easier.
2.Certificates can be forged, and above all highjacked. How many Windows users do you know who actually bother to read those dialog boxes with the Eula and certificate? Exactly, none.

This is besides the point as it will achieve nothing in the end. The real problem is Apple's launchServices, not signed applications. It's up to Apple to fix them, not the ISVs.

[SMacTech]

Originally posted by theolein:

2.Certificates can be forged, and above all highjacked. How many Windows users do you know who actually bother to read those dialog boxes with the Eula and certificate? Exactly, none.
[/B]

Or someone with a grudge and extra $$$ can simply steal another cert, get one themselves, albeit with forged credentials. Signed apps is not the answer as you stated, and I would really be pi$$ed if I had to do that with my apps for OS X.

[joltguy]

Sorry if I've missed this somewhere in this massive thread but since this exploit affects basically all browsers on the Mac, does it follow that Panther's Mail.app would be vulnerable to due to it's reliance on WebKit? I know someone here posted that you could be affected just by viewing a page, what about viewing an HTML email?

BTW, smeger... thanks a million for PA, its given me more peace of mind than the security update has. Seems to me from reading this thread that a proper patch will require that much more than HelpViewer be touched.

[Spheric Harlot]

Originally posted by Developer:
E-mail based certificates are available for free or cheap ( see http://www.thawte.com ). Even if a Shareware author doesn't want to go through the trouble of getting a certificate, most of them have one product, so clicking a dialog "Trust this app?" once is the same as the "Trust this vendor?" dialog for vendors with certificates. That's no major disadvantage for share- and freeware authors.

This brings back memories of hacking the Get Info and vendor info strings of apps with ResEdit in System 6-8...

I'm sure that kind of stuff is MUCH easier to do in OS X .app bundles.

C'mon, Developer, you want to keep stuff at least *slightly* challenging. Nobody'll want to beat the system if there's no effort involved at all! </sarcasm>

-s*

[piracy]

Originally posted by joltguy:
Sorry if I've missed this somewhere in this massive thread but since this exploit affects basically all browsers on the Mac, does it follow that Panther's Mail.app would be vulnerable to due to it's reliance on WebKit? I know someone here posted that you could be affected just by viewing a page, what about viewing an HTML email?

No, this won't work. The "exploit" depends on several things working together, and one of those things is two META REFRESH tags in two frames in a web page. You wouldn't be able to duplicate this functionality in anything but a browser.

[Developer]

Originally posted by theolein:
1.So we all have to fork over money now if we want to develop an acceptable application for Mac OSX? Why don't we just use Windows, it's easier.

No, you don't need to fork over money to develop an acceptable application, since a user can still choose to trust individual (or for all I care all) untrusted applications. All the user has to do then is to acknowledge once with a single dialog that he trusts the app. And it was you who suggested a warning dialog that asks whether an app is trusted before it is launched the first time. Let me repeat that:

You suggested a dialog that asks whether an app is trusted or not!

Signing apps just allows to trust on a vendor basis instead of an app by app basis that you suggested.

2.Certificates can be forged, and above all highjacked.

That remains to be seen. It would certainly not be as simple as editing an Info.plist as you suggest.

The real problem is Apple's launchServices, not signed applications.

LaunchServices needs to fixed here, yes.

[dan7352]

Originally posted by theolein:
The thing is that you've been on on your signed application trip for a while now, ever since that demonstration mp3 trojan came about, IIRC. One size does not fit all.

I've been on the signed application trip ever since the first trojans appeared on bulletin boards. About 15 years ago a friend of a friend of mine wrote a cool freeware application to generate, apply and verify digital signatures and developed the concept of a web of trust so you don't have to pay anyone for a certificate.

[sniffer]

Originally posted by piracy:
No, this won't work. The "exploit" depends on several things working together, and one of those things is two META REFRESH tags in two frames in a web page. You wouldn't be able to duplicate this functionality in anything but a browser.

Agree, it shouldn't be such a big issue. But it's still disturbing that the help:runscript= worked at all in mail.app. WTF is the purpose of that? Pass itms: links through mail? You can only speculate on what Apple have been thinking here.

[theolein]

Originally posted by Developer:
No, you don't need to fork over money to develop an acceptable application, since a user can still choose to trust individual (or for all I care all) untrusted applications. All the user has to do then is to acknowledge once with a single dialog that he trusts the app. And it was you who suggested a warning dialog that asks whether an app is trusted before it is launched the first time. Let me repeat that:

You suggested a dialog that asks whether an app is trusted or not!

Signing apps just allows to trust on a vendor basis instead of an app by app basis that you suggested.That remains to be seen. It would certainly not be as simple as editing an Info.plist as you suggest.LaunchServices needs to fixed here, yes.

You're misrepresenting what I wrote, I think. A few pages back I suggested adding a security layer to Launchservices, similar to what you now get when you run Apple's installer, i.e. a confirmation dialog where you have to input your admin user name and password. There's a good reason why I suggest that over digitally signing applications, and the reason is that digitally signing applications can be bypassed or hacked, and no, it wasn't me who suggested that it was a simple matter of editing info.plist strings, that was Spheric (read the posts again). It is, IMO, not worth the extra hassle to force developers to get their applications signed, because that would very probably drive many shareware/small application developers away from the market.

The one thing that Apple could do, something that is already part of Linux is to simply give every single application that is downloaded permissions of 600. Try this on Linux. You cannot download an application that has executable bits set. It would mean that the security dialog would be needed to give every application permission to run the first time, and only the first time. This would eliminate the current crop of vulnerabilities without forcing a major rewrite of applications, I think.

But who knows, maybe signing applications is the way of the future. But I really hope it isn't.

[joltguy]

Originally posted by piracy:
No, this won't work. The "exploit" depends on several things working together, and one of those things is two META REFRESH tags in two frames in a web page. You wouldn't be able to duplicate this functionality in anything but a browser.

Thanks for the clarification. I did a couple of quickie tests myself and it seems that Mail.app disregards IFRAMES and JavaScript events of every sort. Good stuff.

[Developer]

Originally posted by theolein:
But who knows, maybe signing applications is the way of the future.

Since at thawte you can now purchase certificates "for use with a future Apple Mac OS", it appears to be the future. How it turns out we will have to see when it's there for some time.
It's nothing we should become enemies over.

[Mediaman_12]

Originally posted by joltguy:
Thanks for the clarification. I did a couple of quickie tests myself and it seems that Mail.app disregards IFRAMES and JavaScript events of every sort. Good stuff.

Apple probbaly noticed the sh*t that MS has got into by allowing 'Full' HTML/web browser rendering in the default mail app (re. Outlook Express) and decided they didn't need all that grief, and created some (sensible) restrictions.

[Spades]

Digital signing isn't the answer. Digital signatures are for the paranoid. There are plenty of cases that paranoia is justified (for example, you bet I verified that Gentoo Linux ISO I downloaded), but using it for every single application would be going too far.

For one thing, how do you establish trust? I don't like the certificate signing authority idea. That doesn't seem to eliminate the need to establish trust. It just changes who you need to trust and how much. I, for one, don't trust companies like Verisign. They're out to make money, not establish security. I doubt they do any checking on the people requesting the certificates, other than seeing if the check clears. Nor do I expect their signing certificates are physically protected as well as they should be.

And, as people have said, what of the small developer? They can self-sign, but what happens then? Either they can't be allowed to self-sign, or a dialog will come up asking if the user wants to run the application anyways. Guess what most people are going to click.

In any case, cryptographic signatures solve a fundamentally different problem than the one that's happening here. Signatures solve the problem of authentication. That is, they prove the program was really created by who it claims to have been created by.

The problem of Launch Services registering new handlers is a problem of authorization though. What is the action that tells Launch Services that the user wants a new handler registered? The problem is that the authorization Launch Services uses is putting the file on the computer. That's just plain wrong. The authorization action needs to be something that requires user interaction, at the very least. Personally, I think having to launch the application first is good enough, but requiring admin privileges isn't a bad idea either.

We can argue about digital signatures until the cows come home, but they don't really have anything to do with the security problems this thread is about.