[Eug Wanker]

Originally posted by MindFad:
I'm sure Apple will fix this ASAP, but I'm surprised something that seems quite simple even got by them. Such a simple little loophole, yet possibly very devastating to one's data. I'm thinking Apple should be all over this and have an update by Tuesday. Maybe I'm taking this a little too seriously?

Well, the Help Viewer Safari exploit been known to Apple since February...

They should have been all over this 3 months ago, not May 24.

[theolein]

Originally posted by VValdo:
Just got here late to the thread...

The savings grace is that this relies on user action (ie, visiting a bad web page), but does anyone see a scenario where the mal-code would spread itself via social engineering -- ie, either automatically IMing users in an iChat buddy list or sending an email message to Address Book people directing OS X users to the page with the malignant code?

W

All of those are possible. The most likely actual users of this exploit probably wouldn't be script kiddies, although they would certainly do it if they could, it would be spammers most likely who would use a hole like this combined with a webpage and a mass mailing (Hallo, calling all mac.com users for instance). They could even be really clever and combine the link in the mail with a browser detection script server side and present a page that provides either a pc or mac exploit, depending on the browser.

[Logic]

Security Update 2004-05-24 delivers a number of security enhancements and is recommended for all Macintosh users. This update includes the following components:


HelpViewer

Can you guys check if this fixes this problem?

edited to add: no restart required.

edit nr. 2: spelling.

[mitchell_pgh]

Originally posted by theolein:
All of those are possible. The most likely actual users of this exploit probably wouldn't be script kiddies, although they would certainly do it if they could, it would be spammers most likely who would use a hole like this combined with a webpage and a mass mailing (Hallo, calling all mac.com users for instance). They could even be really clever and combine the link in the mail with a browser detection script server side and present a page that provides either a pc or mac exploit, depending on the browser.

I'm kind of upset that there is a possibility that someone can have me download an applescrips and delete my HD. That's just crazy and unacceptable. Apple should have as many engineers working on this as it takes and show that they are serious about security.

[VValdo]

Originally posted by theolein:
All of those are possible. The most likely actual users of this exploit probably wouldn't be script kiddies, although they would certainly do it if they could, it would be spammers most likely who would use a hole like this combined with a webpage and a mass mailing (Hallo, calling all mac.com users for instance). They could even be really clever and combine the link in the mail with a browser detection script server side and present a page that provides either a pc or mac exploit, depending on the browser.

Yeah, I'm trying to envision a way that this bug can be exploited in a self-propogating way, and it doesn't seem too hard. Not for kiddies to execute as a script, but as a worm/virus.

As you say, because mac users are such a small percentage of the internet, this exploit could be combined with a PC worm w/autodetection of what payload to use. Or it could work within the OSX community, by (1) social engineering (automatically spamming Address Book and Buddy List members to a particular evil URI) . I suppose a worm could turn on apache so that the infected computer serves the infection itself... (2) ...Are there any other protocols or OSX-specific systems that could be a means of transferance? If I'm understanding this thing correctly, it seems to be able to be triggered lots of different ways besides just rogue web pages... Hmm

Scary.

W

[Hugin777]

Originally posted by smeger:
Developer, 'guikit' is a scheme registered by ShapeShifter, of which I'm also the author. Since I knew for sure it wasn't exploitable, I threw it into the whitelist too.

I think I need to make the whitelist user configurable.

Please note that everyone that hasn't installed ShapeShifter would be vulnerable to an attack using guikit: as the "fantasy" malware URI scheme ! (Edit: of course, using ftp: to "get in")

Edit 2: and if they didn't have RealOne Player then pnm: would be exploitable.

Edit 3: I have updated my exploit example page. - Is version 1.0 of the Paranoid Android still available somewhere ?

[CharlesS]

Originally posted by Hugin777:
Please note that everyone that hasn't installed ShapeShifter would be vulnerable to an attack using guikit: as the "fantasy" malware URI scheme ! (Edit: of course, using ftp: to "get in")

Edit 2: and if they didn't have RealOne Player then pnm: would be exploitable.

Exactly. The app should *only* allow the most basic of protocols such as http: and whatnot which are handled by components provided with the OS. Any other protocols should be added manually via some sort of setup interface.

Until then, the best solution is to remap all the troublesome protocols to Chess (or a specific app for handling them, such as an FTP client, telnet program, etc.) using More Internet.

[smeger]

Originally posted by Hugin777:
Please note that everyone that hasn't installed ShapeShifter would be vulnerable to an attack using guikit: as the "fantasy" malware URI scheme ! (Edit: of course, using ftp: to "get in")

Edit 2: and if they didn't have RealOne Player then pnm: would be exploitable.

Edit 3: I have updated my exploit example page. - Is version 1.0 of the Paranoid Android still available somewhere ?

Damnit, you're right. I'm open to suggestions on what to do regarding the whitelist. Maybe there shouldn't be anything in it.

[turtle777]

Originally posted by MindFad:
I'm sure Apple will fix this ASAP...

Why do you think that ?
As long as there is not continuing pressure from press, Apple might just lean back and think it's done its dues.

Maybe I'm taking this a little too seriously?

What ?
How can you take this TOO seriously ?
This is the most serious security flaw ever found in OS X.
It leaves doors open for easy exploits.

Come on...

-t

edit: layout...

[CharlesS]

Originally posted by smeger:
Damnit, you're right. I'm open to suggestions on what to do regarding the whitelist. Maybe there shouldn't be anything in it.

Well, http: and https: are kind of necessary and should be there by default. AFAIK mailto: can't hurt anything. Everything else could probably be blocked, unless I'm forgetting something.

Adding some sort of interface to the whitelist would let people add protocols for custom apps they're using, and everyone's happy. Maybe you could add a little checkbox on the warning dialog that says "Always allow this protocol" so that it would be quick and painless for users - the first time PA blocked some protocol they wanted, they could just check it on.

[turtle777]

Originally posted by Logic:
Can you guys check if this fixes this problem?

Logic, how about reading the thread. It will answer your question.

NO, the SU does NOT fix all the problems.
The only sure fix so far seems to be Paranoid Andoird from Unsanity.

-t

[CharlesS]

FYI: In case anyone is interested, David Utidjian has agreed to host my exploit apps on his server:

http://physics.ramapo.edu/macsploits/

I realize these have become redundant due to someone else putting up the test: exploit already, but thought people may find them useful anyway. These apps are normal .zip files, and demonstrate the fact that these apps really don't need to be stored in .dmg files if you have 'safe' files turned on. Just download and then use either evil: or tn3270: to launch them, depending on which one you download.

[CharlesS]

Originally posted by turtle777:
Logic, how about reading the thread. It will answer your question.

NO, the SU does NOT fix all the problems.
The only sure fix so far seems to be Paranoid Andoird from Unsanity.

-t

Even it has (fairly serious) problems due to its whitelist which allows certain protocols (including FTP) through which it really shouldn't.

The only really sure fix is to:

1. Turn off 'safe' files

2. Remap disk:, disks:, ftp:, afp:, smb:, telnet:, and webdav: to Chess

3. Be careful about what archive files you open

[turtle777]

Originally posted by CharlesS:
FYI: In case anyone is interested, David Utidjian has agreed to host my exploit apps on his server:

http://physics.ramapo.edu/macsploits/

David, in case you read this:

I tried to download or access the files. Your server won't let me.
When directly clicking on it, it refuses due to lack of access rights.
When trying to download to location, it states that the file doesn't exist.

Am I doing something wrong ?

-t

edit: spelling

[Hugin777]

Originally posted by CharlesS:
FYI: In case anyone is interested, David Utidjian has agreed to host my exploit apps on his server:

http://physics.ramapo.edu/macsploits/

There seems to be some permission problems; I just get: "You don't have permission to access /macsploits/evil.zip on this server."

Originally posted by CharlesS:
2. Remap disk:, disks:, ftp:, afp:, smb:, telnet:, and webdav: to Chess

Please note that smb: and webdav: usually does not work in Safari 1.2 under Panther, so only the first four are required to close the two security flaws found in this thread.

Note also that the Paranoid Android version 1.0 may be ok (as it's whitelist is shorter, AFAIK).

[CharlesS]

Originally posted by Hugin777:
There seems to be some permission problems; I just get: "You don't have permission to access /macsploits/evil.zip on this server."

Hmm, I'll have to let him know. Thanks...

[turtle777]

Originally posted by Hugin777:
There seems to be some permission problems; I just get: "You don't have permission to access /macsploits/evil.zip on this server."

Good, so it's not me that is too stupid.

Btw, having installed PA and Little Snitch seems to make it a double barrier.
So far, on all exploits, I had to click at least twice.
I'd like to see that if PA would NOT catch it, maybe Little Snitch still pops up...

-t

[fukami]

Has someone recognized how many Cross Site Scripting holes are out there? Who would i.e. think that there is an XSS at Niels Haydens website? Or VT (I have mailed them about that issue some months ago -- but I got no response at all). If you add an iframe or a script src to their vulnerable scripts you have one of the different methods to give users URIs from "trusted domains"

I've also considered to remap all the protocols.

[fukami]

Shissshh ...

XSS on apple.com loading Jasons exploit demo

[theolein]

Originally posted by fukami:
Shissshh ...

XSS on apple.com loading Jasons exploit demo

Isn't it just wonderful when apple casually acts as a spreader of malicious applications. (Although the apple.com idea would fool a lot of people, the same trick could be pulled with many a site using iframes.)

Ha. Now try this everyone: Type applescript:// into Safari......



Scripteditor starts up. I have no idea how one could otherwise abuse this (commands that one could pass through the string etc)

[Developer]

Originally posted by theolein:
Ha. Now try this everyone: Type applescript:// into Safari......

Scripteditor starts up. I have no idea how one could otherwise abuse this (commands that one could pass through the string etc)

Hello Applescript


It can not be abused, because AppleScripts are only passed to the ScriptEditor (pasted into the document), but never executed.

http://www.apple.com/applescript/scripteditor/12.html

They explicitly say they considered security.

[CharlesS]

Originally posted by Developer:
Hello Applescript


It can not be abused, because AppleScripts are only passed to the ScriptEditor (pasted into the document), but never executed.

http://www.apple.com/applescript/scripteditor/12.html

They explicitly say they considered security.

Too bad the AppleScript people didn't write Help Viewer and the URL handling mechanism.

[theolein]

Originally posted by Developer:
Hello Applescript


It can not be abused, because AppleScripts are only passed to the ScriptEditor (pasted into the document), but never executed.

http://www.apple.com/applescript/scripteditor/12.html

They explicitly say they considered security.

It's nice of them NOT to have included a "run" command. That would have been fun.

[MindFad]

Originally posted by turtle777:
What ?
How can you take this TOO seriously ?
This is the most serious security flaw ever found in OS X.
It leaves doors open for easy exploits.

Come on...

-t

Uh, yes, which would be exactly why I thought Apple would fix this pretty quickly.

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

[utidjian]

Originally posted by turtle777:
David, in case you read this:

I tried to download or access the files. Your server won't let me.
When directly clicking on it, it refuses due to lack of access rights.
When trying to download to location, it states that the file doesn't exist.

Am I doing something wrong ?

Nope, you are doing nothing wrong. It was my mistake.Fixed.

Sorry about that. I was using my Linux box at the time... one of those annoying ease-of-use things with Linux, no matter what you download: email attachments, or files of any type via Mozilla (or any browser/email reader) the mode is always set to 0600 regardless of how it is set at the point of origin. Annoying... but probably a good thing. Makes it much harder to spread malware via email.

I made the mode on those files 0755. When they are unzipped the contents have the permissions as Charles originally set them.

If you have any more problems let me know.

[Eug Wanker]

Originally posted by MindFad:
Uh, yes, which would be exactly why I thought Apple would fix this pretty quickly.

I hope so too, but like I said, it took them several months to fix the Help Viewer exploit.

[Person Man]

Originally posted by Eug Wanker:
I hope so too, but like I said, it took them several months to fix the Help Viewer exploit.

Yes, but they still seem (key word: SEEM) to be more responsive to security holes than Microsoft is... I just heard that it took Microsoft SEVEN months from the time the LSASS security hole was reported until they released a patch for it. Then someone released the Sasser worm within a week after Microsoft announced they had a patch.

It took Apple "only" three months...

To be fair, Apple is probably working on the other related problems now. Give them *at least* a month to properly code a working solution for this one (i.e. write it, and test it *PROPERLY*, before releasing it), because the problem is one that is deeply rooted in the operating system, and needs a well-thought-out fix.

[gatekeeper]

Originally posted by Person Man:
I just heard that it took Microsoft SEVEN months from the time the LSASS security hole was reported until they released a patch for it.

Windows Local Security Authority Service Remote Buffer Overflow:

Release Date:
April 13, 2004

Date Reported:
October 8, 2003

[BerylliumSphere]

Originally posted by turtle777:
Good, so it's not me that is too stupid.

Btw, having installed PA and Little Snitch seems to make it a double barrier.
So far, on all exploits, I had to click at least twice.
I'd like to see that if PA would NOT catch it, maybe Little Snitch still pops up...

-t

Hi. I'm new to the discussion, please be gentle if I've missed something obvious.

Do I understand right that this is not a root exploit?

In that case why not limit the potential damage by doing all your web surfing from a separate user account with nothing important in its home directory?

You'd still have the following problems:
o an exploit could send out spam or embarrassing email
o a URI exploit might be combined with a privilege escalation exploit
o there could be unauthorized access to files in the Shared directory
o you'd have to copy your bookmarks over
o saving interesting files would be a pain
o sooner or later you'd forget and click a link while in your main account.

Thanks,

Fred

[Person Man]

Originally posted by gatekeeper:
Windows Local Security Authority Service Remote Buffer Overflow:

Ok... 5 1/2 to 6 months. Still slower than Apple.

[CharlesS]

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

Not a bad idea. And it could be programmed to set off whenever any app which was going to launch was sitting on a removable drive, a disk image, a server, or the Desktop.

[brazil]

I was just wondering if Opera has this vulnerability . I looked in over at their forums and the only post I found about it said Opera was NOT affected . Thanks for any advice and all that many here have done in the face of this situation .

Opera Forum Link

[alcatholic]

Originally posted by CharlesS:
Exactly. The app should *only* allow the most basic of protocols such as http: and whatnot which are handled by components provided with the OS. Any other protocols should be added manually via some sort of setup interface.

Until then, the best solution is to remap all the troublesome protocols to Chess (or a specific app for handling them, such as an FTP client, telnet program, etc.) using More Internet.

There is a chance that no protocol is safe.

When Developer first brainstormed on what was the possible trouble caused by LaunchServices, he listed three possibilities, below are his words. The first two have been proven by Charles S and smeger. Did anyone test the third, i.e. increasing the version number of an existing app? If it works then no protocol is safe, right?

http://forums.macnn.com/showthread.p...=5#post1995063
*******
Then LaunchServices got smarter. If showing with file: is sufficient that could be used maybe.

But you'd need have a protocol that is by default assigned to an application that is not installed. I see several non assigned protocols in MisFox bot none is assigned to a not installed application.
One could also try to mount an image with a application that advertises a phantasy protocol, show it and then - if showing is enough to make LaunchServices to register the protocol - run it with the phantasy protocol URL.
Other idea would be to put a malicious app onto the disk image with the same creator code (and name if you want) as an existing registered application for a protocol (lets say again Help Viewer), but with a higher version number. LaunchServices might then maybe launch the "more recent" version of the app.

All three worth to try.

(but I'm too lazy to do so)
*************

BTW, RCDefault does not seem to allow me to add protocols to block. How do I add protocols to RCD? Should I get More Internet instead?

To match what I understand to be the authoritative list of protocols that can help malware register in LaunchServices, I need to add:
disks:
smb:
webdav:

I have already blocked:
ftp:
disk:
afp:
telnet:

[sniffer]

Originally posted by alcatholic:
Did anyone test the third, i.e. increasing the version number of an existing app? If it works then no protocol is safe, right?

If you're right, you could simply zip a fake or manipulated help viewer (and what about a fake ShapeShifter to get around PA?) with a bad script, and you're basically back to stage one.

[Hugin777]

Originally posted by alcatholic:
There is a chance that no protocol is safe.

When Developer first brainstormed on what was the possible trouble caused by LaunchServices, he listed three possibilities, below are his words. The first two have been proven by Charles S and smeger. Did anyone test the third, i.e. increasing the version number of an existing app? If it works then no protocol is safe, right?
[..]
*************

BTW, RCDefault does not seem to allow me to add protocols to block. How do I add protocols to RCD? Should I get More Internet instead?

[..]I need to add:
disks:
smb:
webdav:

To take the last thing first. Try smb: and webdav: in Safari. They don't work. Only disk:, disks:, ftp:, and afp: are needed (if file: and ssh: are safe, and auto-open is off). Also, Internet Explorer can do this too (and MisFox).


Regarding the third potential vulnerability:

According to this document, under "Document Binding Criteria":

7. Break any ties of the same application by choosing the latest version number.

- It should be possible.

Note that this document states that:

Whenever a new application becomes known to the system (such as when the user drags it from an installation disk into the Applications folder), the application is registered with Launch Services, which copies the needed information about the application into its database.

- It seems like the intent wasn't to register URLHandlers (or Application Codes?) from remote locations initially

[Hugin777]

Originally posted by sniffer:
If you're right, you could simply zip a fake or manipulated help viewer (and what about a fake ShapeShifter to get around PA?) with a bad script, and you're basically back to stage one.

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?).

I didn't even have to specify "itms" in the list of CFBundleURLSchemes.


Edit: I have notified [email protected] once more, with the list of the three vulnerabilities CharleS, smeger and Developer found in this thread. Two of them could be fixed if LaunchServices wan't updating it's database so readily, the third could be fixed by removing some URLHandlers from the default installation. AFAIK

[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. The automated version of ALL methods works without user interaction in the default configuration of Mac OS X.

(The site uses Unsanity's "OSXMalware.app" example, renamed to "test.app" with the URI handler changed to "test:")

[[APi]TheMan]

With the May 24th Security Update from Apple help:runscript still launches Help Viewer, that's gross. I wish they'd tell us exactly what they changed to 'fix' it.

edit:

Originally posted by piracy:
Security Update 2004-05-24 for Mac OS X 10.3.3 "Panther" and Mac OS X 10.3.3 Server

HelpViewer: Fixes CAN-2004-0486 to ensure that HelpViewer will only process scripts that it initiated. Credit to lixlpixel <[email protected]> for reporting this issue.

What more do you need to know? It fixes the issue of being able to pass scripts *to* HelpViewer, which was the problem.

That's all I needed to know. I forgot to look at the explanation in Software Update and nobody had posted the release notes of the patch in this thread. Anyways, thanks.

side note: My god, when did Camino get hit by the looping GIF bug like Safari? The edit post page is horrible in Camino and my system slows to a crawl when those images are in view. At least the initial reply page has the textarea box somewhat far from the images so you can scroll them out of the view.

[piracy]

Originally posted by [APi]TheMan:
With the May 24th Security Update from Apple help:runscript still launches Help Viewer, that's gross. I wish they'd tell us exactly what they changed to 'fix' it.

Security Update 2004-05-24 for Mac OS X 10.3.3 "Panther" and Mac OS X 10.3.3 Server

HelpViewer: Fixes CAN-2004-0486 to ensure that HelpViewer will only process scripts that it initiated. Credit to lixlpixel <[email protected]> for reporting this issue.

What more do you need to know? It fixes the issue of being able to pass scripts *to* HelpViewer, which was the problem.

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