[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.

[alcatholic]

Originally posted by sniffer:
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.

And, if I may add to your point, URL's should not launch apps that are on mounted volumes, network folders, and the desktop. You can of course still launch apps located in those locations by using more trusted means, e.g. double clicking, applescripts, etc.

But someone mentioned this is a trap, as you can't be sure your exceptions will be safe, or something like that. I may have misunderstood the post.

[Diggory Laycock]

http://www.versiontracker.com/dyn/moreinfo/macosx/23463

PA 1.2 is out by the look of it.

[CharlesS]

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.

Exactly. Remember that these certificates will be static, and every hacker who wants to will be able to look at them and have infinite time to analyze them, and crack them. And if digital signatures are required, this will happen, because it's a basic law of software protection that any scheme you come up with will eventually get cracked, no matter how good it is. This will lull people into a false sense of security, and cause people to open any app that has Apple's or MS's or whoever's signature on it, because they will think it's 'safe'.

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.

Well, the problem with this is it relegates us shareware and freeware developers to second-class citizen status. You can go with a "real" app from a bloatware developer like M$, or you can use a shareware app and get warned that the developer isn't trusted.

Originally posted by Diggory Laycock:
http://www.versiontracker.com/dyn/moreinfo/macosx/23463

PA 1.2 is out by the look of it.

Great, this version looks much more effective than the previous one.

[CharlesS]

Originally posted by sniffer:
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.

Ah. This would be okay as long as you could still get LS to cache the app's info by launching the app.

[smeger]

Personally, I still think that the solution to this problem is don't register scheme handlers until the app has been executed.

This neatly solves all of these exploits in that you can't get an app to launch by using a new or hijacked scheme because the app can't launch until the app has launched, creating a Catch-22 for the malware author.

This isn't a generalized cure for security issues, of course - it doesn't solve exploitable problems in legit software that's already got registered scheme handlers (the telnet, help viewer and ssh exploits, for example). But, I believe that the responsibility for fixing these sorts of exploits lies with the vulnerable apps, not with the operating system. Putting the burden of preventing all possible exploits onto the OS creates an unrealistic situation.

I don't like the idea of signed apps. As others have said, they're hackable and give a false sense of security, and as a small shareware developer myself, I can definitely appreciate the idea that they'd make us into second class citizens. Even more importantly, they give the user the idea that "signed" companies write software that's somehow more secure and reliable than "unsigned" companies, which I'm not at all sure is the case.

On another note, I tried pretty hard to get Paranoid Android to prompt the user whenever a new scheme handler is registered, but wasn't able to get it working 100% of the time (it failed when a new volume with a new app was mounted, which is the most important time you want it to work). But in the process, I noticed that what's causing the scheme handler to be registered is that the Finder asks Launch Services for the "display name" of the app. Launch Services loads in everything else in the process, and the scheme handlers get registered.

[sniffer]

Originally posted by smeger:
Personally, I still think that the solution to this problem is don't register scheme handlers until the app has been executed.
[..]
This isn't a generalized cure for security issues, of course - it doesn't solve exploitable problems in legit software that's already got registered scheme handlers (the telnet, help viewer and ssh exploits, for example). But, I believe that the responsibility for fixing these sorts of exploits lies with the vulnerable apps, not with the operating system. Putting the burden of preventing all possible exploits onto the OS creates an unrealistic situation.

Wouldn't that mean updated versions of an app would not be registered by LS until you run them for the first time? So in other words there is a potential issue of inconvenience here.
Also not sure if I follow you on why the OS shouldn't have some responsibility in what app should be granted insecure documents/passing of urls or not? The Help Viewer exploit shouldn't happen in the first place, and I don't see the logic in it being possible to forward url handlers to Chess.app either, as neither is designed for handling insecure documents in the first place.
Perhaps it's just me that doesn't fully understand the basic behind how security concepts in a OS works, or something. I don't know.. I just don't trust Apple patching this will give me comfort. It would need rethinking.

(Perhaps I am just to idealistic without really understanding the full picture.)

Edit: Looks like a nice PA upgrade. Installing it now.

[alcatholic]

Originally posted by smeger:
Personally, I still think that the solution to this problem is don't register scheme handlers until the app has been executed.

... I noticed that what's causing the scheme handler to be registered is that the Finder asks Launch Services for the "display name" of the app. Launch Services loads in everything else in the process, and the scheme handlers get registered.

Agreed, but I would clarify OS X can continue to register creator codes and everthing else upon viewing. It just should not register the URL schemes until launch. Would it be safe to allow official installers to register URL schemes? I guess so, as the installer could not be launched via a URL.

Matt Neuberg has a great article explaining how the URL scheme registration entered OS X. Great read. I found the link from Sander Tekelenburg�s wepage:
http://www.euronet.nl/~tekelenb/play...hemes/#tidbits

BTW, since you allow mailto: is it possible to hijack that scheme? I guess you would have to know a person's default mailto: helper app and hijack it with a higher version number. Question, once a scheme, say itms: is assigned, how can another app take it over? Must the user manually change it with RCDefault, More Internet or whatever? Can an installer take it over? Would it require user permission somehow?

[sniffer]

smeger: I think I've might have run into a bug here..
Not sure if it's a big issue or not, but here it goes:

Adding "file" to the white hat list solved it for me.

[CharlesS]

Originally posted by alcatholic:
Agreed, but I would clarify OS X can continue to register creator codes and everthing else upon viewing. It just should not register the URL schemes until launch. Would it be safe to allow official installers to register URL schemes? I guess so, as the installer could not be launched via a URL.

Well, I agree that it is nice to have the traditional Mac behavior of caching creator codes on viewing. But we need to have some way to prevent my tn3270: creator code exploit...

[theolein]

Originally posted by CharlesS:
Well, I agree that it is nice to have the traditional Mac behavior of caching creator codes on viewing. But we need to have some way to prevent my tn3270: creator code exploit...

I still think the Linux way of simply enforcing ALL downloads to have permissions 600 is the best bet and that you either go and change them in the terminal (for terminal junkies) or else the Finder (via launchServices) prompts you with an admin password request upon first launch, since the Finder would recognise an application either by its .app extension and info.plist or by its APPL type resource.

[utidjian]

Originally posted by Diggory Laycock:
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. [/B]

Why not use a free signing system like PGP or GnuPG? Using a free signature system would eliminate the preference for those that can afford it... levels the playing field.

[utidjian]

Originally posted by theolein:
I still think the Linux way of simply enforcing ALL downloads to have permissions 600 is the best bet and that you either go and change them in the terminal (for terminal junkies) or else the Finder (via launchServices) prompts you with an admin password request upon first launch, since the Finder would recognise an application either by its .app extension and info.plist or by its APPL type resource.

I would like to clarify that... ALL downloads via a web browser in Linux are set to mode 0600 on the receiving end. Also ALL email attachments are set to 0600 (they are considered downloads). However, tools such as wget, curl, scp, rsync, and ftp (basically anyhting that is a CLI command) will usually save the downloaded files with the same bits set as the origin. If it is a tarball or RPM the bits will be set as the original or as specified on expansion.

For all intents and purposes any file you click on in a web browser that downloads to your machine has its mode set to 0600. The only exception to this that I know is if, for instance, you click on a plain text file (such as a script) it will display in your browser as plain text. Then you can choose File --> Save Page As and it will then save it with mode 0644. Never with any odd mode (with the x bits set). If you Shift-Click on a plain text file it will download with mode 0600 (treated same as regular download).

This can be an annoyance... but is easily but deliberately fixed.

[alcatholic]

Originally posted by CharlesS:
Well, I agree that it is nice to have the traditional Mac behavior of caching creator codes on viewing. But we need to have some way to prevent my tn3270: creator code exploit...

You're right...and we need to prevent App Hijacking!

So,

allowing auto-registration of url schemes allows the phantasy protocol exploit.

allowing auto-registration of creator codes allows the tn3270: and app hijacking via version number exploits.

Looks like checkmate once an app gets registered.

I think I finally understand this thing.

[alcatholic]

Originally posted by Diggory Laycock:
http://www.versiontracker.com/dyn/moreinfo/macosx/23463

PA 1.2 is out by the look of it.

Thank you, smeger. Your dedication is awesome! I totally admire your efforts at trying to intercept whenever LS registers an app. That is probably exactly what Apple should be doing for us.

One thing, in theory, I don't think PA can protect against App Hijacking. In practice, I guess it could, as whose going to allow any app to launch when they are just looking at a webpage.

Well, I take that back. If the webpage was to display a quicktime movie or something I would click yes when the quicktime: scheme, or whatever, wanted to launch Quicktime. Of course if I knew that this "Quicktime" was located someplace strange, I would say no. So how about it? PA 1.3 letting us know somehow "which Quicktime" wanted to launch.

Of course, I may be wrong about PA allowing App Hijacking, and it certainly is not your job to keep us safe.

[alcatholic]

Originally posted by Developer:
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.

Wow, this reminds me of the general solution Peter de Silva spelled out in his open letter to Apple, http://scarydevil.com/~peter/io/osx-security.html

I can't understand Apple, though: there should be at least *two* unrelated sets of bindings... one to be used for applications that work with local documents and one for applications that work with untrusted documents... and the bindings for applications that work with untrusted documents should be *absolutely* minimal.

When I first posted de Silva's letter I totally overlooked/didn't understand his point. I got lost in the trusted/untrusted helper apps part that follow this point.

You see, with two sets of bindings the one the browser uses just won't be updated automatically. The Finder can still keep its creator codes and all that automatic goodness. As far as I can tell, sounds like de Silva is on to something.

[Spades]

Originally posted by utidjian:
Why not use a free signing system like PGP or GnuPG? Using a free signature system would eliminate the preference for those that can afford it... levels the playing field.

Are you going to trust that signature though? I could create a signing key for a user known as E. Vile Person ([email protected]) and sign applications with that. What kind of infrastructure will you use to ensure that people don't use fake signatures? If you're going to accept just any signature, you're back to square one. Signatures are not the ultimate solution. They require some degree of trust establishment, yet establishing that trust is going to exclude people you might not want to exclude. You need some allowance for unsigned applications that doesn't scare people unnecessarily.

[utidjian]

I think people are dismissing the signing of applications too readily. Most of the disadvantages that some have mentioned are avoidable or don't really exist.

• There are signing methods that are free: PGP GnuPG
  It is, for all practical purposes, impossible to crack a public key by brute force alone. Something on the order of tens of millions of years with current key lengths.
  When an application is signed with a public key it does not guarantee that the application itself is bug free. It insures that the application is authentic. It insures that it has not been altered since it was signed by its creator.
  It does not insure that the application is trustworthy. It insures that that the copy of the application that one downloaded is trustworthy.
  A cracker does not have infinite time to crack on a public key unless a cracker has an infinite lifespan.
  A public key signed application does not insure who the creator is, that is what Verisign claims to do.
  A public key signed application can insure that the app was signed by the creator of the app.
  The only reason to create a new public key is if the creator thinks the private key has been compromised.

For instance: If someone creates a shareware application and it gets distributed one can be pretty damn certain that the copy of the application one downloads is the one distributed by the creator if it has the correct signature.

[CharlesS]

Not again! Sorry, double post

[CharlesS]

Originally posted by utidjian:
There are signing methods that are free: PGP GnuPG

Yes, but like others have said, how do you know that the signature is valid? There has to be some sort of trusted server you can connect to in order to verify the signature. And that service may not be free. If it costs hundreds of dollars, that is severely eating into the already small income of shareware developers. Freeware devs are completely shut out.

It is, for all practical purposes, impossible to crack a public key by brute force alone. Something on the order of tens of millions of years with current key lengths.

Yeah right! I highly doubt your statistics without links to back them up. Even if they were true, don't forget that computer processing power increases at a blistering rate. And those signatures are static.

When an application is signed with a public key it does not guarantee that the application itself is bug free. It insures that the application is authentic. It insures that it has not been altered since it was signed by its creator.

No offense, but so what?! Okay, so I know that this evil app that has erased my home folder by registering itself as a tn3270: link has not been modified since the evil hacker created it. Oh boy, that's a great consolation!

[utidjian]

Originally posted by Spades:
Are you going to trust that signature though? I could create a signing key for a user known as E. Vile Person ([email protected]) and sign applications with that. What kind of infrastructure will you use to ensure that people don't use fake signatures? If you're going to accept just any signature, you're back to square one. Signatures are not the ultimate solution. They require some degree of trust establishment, yet establishing that trust is going to exclude people you might not want to exclude. You need some allowance for unsigned applications that doesn't scare people unnecessarily.

I think you misunderstand what public/private key signatures do.

If I want some shareware/payware/freeware from someone called E. Vile Person or Steve Jobs or Spades it makes no difference. I want to be able to grab it off their site or a mirror site and know it was made and signed by them. Public/Private key signature schemes insure that. If I download some app from someplace (even the vendors website) and the package fails the signature test I can be sure that they didn't sign it (or that I have a bad copy).

The only infrastructure one needs for getting genuine public keys is for the creator(s) to publish them on their website(s). Simple.

It is very difficult to establish trust with anyone for that matter. But one tends to trust at least a few vendors. What public/private key signatures do is allow me to trust that the software I download is really from the vendors I trust.

How does one know that the software one downloads from VersionTracker or MacUpdate are really from their creators and not from someone else?
If it was a signed package I could go to the original creators website and get a copy of their public key once.... then any software that claims to be created by them could be checked for having the correct signature.

Here are some links for PGP/GnuPG:

http://www.rpm.org/max-rpm/ch-pgp-intro.html
http://www.pgp.com/
http://www.pgpi.org/
http://www.gnupg.org/