[kampl]

Originally posted by sniffer:
You do just as you please. This thread is not a help desk, and none of us are responsible for what happens to your machine. Wait for the Apple patch if you don't feel comfortable with our suggestions for workarounds. This is pretty much a spanking new security flaw for 99.98% of the posters in here. We find the alternative paths as we go. No one have a manuscript here. If you don't know what is going on, please take the time to start reading the thread from post #1.

So much for the appreciation ..

I was actually curious regarding what other people are doing. A third party app for this is not what is mass-deployable by any means and there is the fact that this is not something approved by Apple. Great solution. Perhaps it works for people, but perhaps there is a better way? No?

[CharlesS]

Originally posted by Developer:
From observation LaunchServices appears to register a program only when it's in one of the Applications folders at log-in or when it is has been launched by double-clicking at least once. So this currently wouldn't work because LaunchServices doesn't know about any apps on the freshly mounted image.

(didn't test it though; maybe LaunchServices got smarter meanwhile and this works now, but I don't think so)

WRONG, all that's needed is to browse into the folder containing the app. Don't believe me? I tested this before I posted about it. Here's what I did.

1. Prepared a disk image on a different Mac with a disk image containing a copy of the Chess app (Chess because that is what my help: protocol is mapped to at the present time).

2. Put the image on a USB flash drive.

3. Went to my primary Mac and deleted the Chess app (making sure to archive a copy in a .zip file first).

4. Tested a help: URL. It launched Chess from my 10.2 partition. Oops, forgot about that.

5. Got rid of the Chess app on my 10.2 partition. The help: protocol now opens its default app, Help Viewer.

6. Inserted the USB flash drive into my primary Mac.

7. Mounted the disk image.

8. Typed a help: URL into Safari.

9. The Chess app on the disk image on my USB flash drive opened.

That's all there is to it. You can try it yourself if you'd like. If your disk image doesn't open automatically, you may have to get the Finder to browse into it. This is easy enough to do with a file:/// URL, although a malware writer could just make the DMG auto-open.

[CharlesS]

Originally posted by kampl:
I was actually curious regarding what other people are doing. A third party app for this is not what is mass-deployable by any means and there is the fact that this is not something approved by Apple. Great solution. Perhaps it works for people, but perhaps there is a better way? No?

Seriously, at the present time, no.

[kampl]

Originally posted by CharlesS:
Well, in addition to the forum, there's VersionTracker (5 star rating):

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

Or MacUpdate (4.5 star rating):

http://www.macupdate.com/info.php/id/12849

Or MacWorld (4.5 mouse rating, twice):

http://www.macworld.com/2004/03/reviews/macgems/
http://www.macworld.com/2003/11/reviews/macgens/

Look, this is a good app, and it's made by an established Mac developer, not some Tom, Dick, or Harry. It is not a patch and was not designed solely to fix this bug. You seem to have trouble comprehending this, but maybe the Macworld review from November 2003 will help you figure out that this has been around for a while and is well known.

Sheesh, people will trust a third party app to repair their whole hard drive, but refuse to use an app designed to allow you to change some protocol helper settings.

OK, Apparently you are taking this pretty light. Nice to be in that world. I assume you do not manage a multitude of Macs in anything resembling a corporate network. How nice. If this is the solution you put your faith in, that is nice. I would not, nor will not. A mitigating strategy for now until Apple puts forth a solution is what is necessary. Make sense?

[n8910]

Originally posted by kampl:
OK, Apparently you are taking this pretty light. Nice to be in that world. I assume you do not manage a multitude of Macs in anything resembling a corporate network. How nice. If this is the solution you put your faith in, that is nice. I would not, nor will not. A mitigating strategy for now until Apple puts forth a solution is what is necessary. Make sense?

So what are you doing to fix? do you ask each user to run that app? do you do it yourself?

I had 400 some macs at work to do.

[CharlesS]

Originally posted by kampl:
OK, Apparently you are taking this pretty light. Nice to be in that world. I assume you do not manage a multitude of Macs in anything resembling a corporate network. How nice. If this is the solution you put your faith in, that is nice. I would not, nor will not. A mitigating strategy for now until Apple puts forth a solution is what is necessary. Make sense?

Well, of course it's a mitigating strategy until Apple releases a patch. Only an idiot would argue against that. As soon as the patch is out, I'll change the protocol back to Help Viewer. But at the present, this is the only way to work around the problem 100%. It works - your solution does not. If I were a malicious hacker, I could bite you and every machine in the lab you've set up this way without breaking a sweat, just by putting a copy of Help Viewer on the disk image.

You know, I saw a Mac at the uni's computer lab that wouldn't start up. It had hard disk problems, and fsck/Disk Utility wasn't able to fix them. It required the use of DiskWarrior to fix it. OH NO, THAT'S A THIRD-PARTY APP!

More Internet is a good app. Two very favorable recommendations in Macworld should at least tell you something...

[Developer]

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)

[kampl]

Originally posted by CharlesS:
Well, of course it's a mitigating strategy until Apple releases a patch. Only an idiot would argue against that. As soon as the patch is out, I'll change the protocol back to Help Viewer. But at the present, this is the only way to work around the problem 100%. It works - your solution does not. If I were a malicious hacker, I could bite you and every machine in the lab you've set up this way without breaking a sweat, just by putting a copy of Help Viewer on the disk image.


You know, I saw a Mac at the uni's computer lab that wouldn't start up. It had hard disk problems, and fsck/Disk Utility wasn't able to fix them. It required the use of DiskWarrior to fix it. OH NO, THAT'S A THIRD-PARTY APP!

More Internet is a good app. Two very favorable recommendations in Macworld should at least tell you something...

Brilliant!!

Now, on a serious note, 3rd party apps have their place, which you obviously have no clue about. A security issue? Yeah, 3rd party all the way for my core OS, good plan. If you have something that makes sense, please chime in. I won't hold my breath obviously on this one.



EDIT:

Show me a sploit (without being a D1CK of course) that my actions have not mitigated? I'm very curious. rm -Rf / is OK but II'd rather not. I have backups.

[CharlesS]

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

On mine, I have TN3270 assigned to a non-existent application. It may be possible to exploit this by making an app with that creator code. However, regardless of whether this will work or not, I know that it is possible to launch an app by opening a disk image containing it when the identical app which is used as the helper app for some protocol has been deleted from the hard disk, because I've tried it.

[CharlesS]

Originally posted by kampl:
Brilliant!!

Now, on a serious note, 3rd party apps have their place, which you obviously have no clue about. A security issue? Yeah, 3rd party all the way for my core OS, good plan. If you have something that makes sense, please chime in. I won't hold my breath obviously on this one.

"Core OS" - WTF? The file ~/Library/Preferences/com.apple.internetconfig.plist is not the core OS. It has nothing to do with the core OS. It's in the frigging home directory, for heaven's sake!

Or maybe you still haven't gotten over the fact that this isn't a patch of any sort, but is a rather ordinary utility application designed to change some settings?

Show me a sploit (without being a D1CK of course) that my actions have not mitigated? I'm very curious. rm -Rf / is OK but II'd rather not. I have backups.

I described one in great detail already. Just look up a few posts and you'll see it. I'm not going to put an exploit on my webspace, because I don't want to get slashdotted. But you are more than welcome to follow the same steps I did and reproduce this for yourself. Of course, you'll have to use Help Viewer rather than Chess as you haven't changed the protocol.

[Developer]

Originally posted by CharlesS:
On mine, I have TN3270 assigned to a non-existent application.

Sorry, my oversight. In MisFox they showed up as "empty", but in MoreInternet I now see that several protocols have actually creator codes of non installed apps assigned.
Well spotted, Charles. And who would have thought that discussing with obnoxious people can be fruitful at times.

[CharlesS]

Originally posted by Developer:
Sorry, my oversight. In MisFox they showed up as "empty", but in MoreInternet I now see that several protocols have actually creator codes of non installed apps assigned.
Well spotted, Charles. And who would have thought that discussing with obnoxious people can be fruitful at times.

I do wonder if this is something we should worry about.

[kampl]

Originally posted by CharlesS:
"Core OS" - WTF? The file ~/Library/Preferences/com.apple.internetconfig.plist is not the core OS. It has nothing to do with the core OS. It's in the frigging home directory, for heaven's sake!

Or maybe you still haven't gotten over the fact that this isn't a patch of any sort, but is a rather ordinary utility application designed to change some settings?


I described one in great detail already. Just look up a few posts and you'll see it. I'm not going to put an exploit on my webspace, because I don't want to get slashdotted. But you are more than welcome to follow the same steps I did and reproduce this for yourself. Of course, you'll have to use Help Viewer rather than Chess as you haven't changed the protocol.

Stretching? plist files are obviously modified by updates. What was it you were driving at again?

I recall portraying this tripe as a patch, but it is not. It is a third party security update Yeah, there is something I would install in an enterprise.

If you "wrote" an exploit that is available for OS X, that works on my platform? Why is it that it is not working on my up to date platform? I've been through every link here. Nope. Thanks for the variant though.

[CharlesS]

Originally posted by kampl:
Stretching? plist files are obviously modified by updates. What was it you were driving at again?

I recall portraying this tripe as a patch, but it is not. It is a third party security update Yeah, there is something I would install in an enterprise.

It is not a third party security update. It is not not not a security update of any kind. For God's sake. It is a utility to change the frigging helper app settings. It was around before this exploit. It was not designed to patch or otherwise correct this hole as it predates the hole. However, it is nonetheless useful in doing so.

If you "wrote" an exploit that is available for OS X, that works on my platform? Why is it that it is not working on my up to date platform? I've been through every link here. Nope. Thanks for the variant though.

Because I didn't provide a link, because as I said already I can't afford to get slashdotted. Construct the DMG with the instructions I gave above (substituting Help Viewer for Chess) and you will see.

[smeger]

Charles, if LaunchServices is becoming aware of an app just by Finder browsing it's directory, there's absolutely nothing from stopping a malware author from writing an app/script that deletes your home directory and setting it as the handler for some made-up protocol in its Info.plist.

In other words, lets' say I write a standard Mac app that deletes the home directory. The Info.plist for this app contains

Code:
	<key>CFBundleURLTypes</key>
	<array>
		<dict>
			<key>CFBundleURLName</key>
			<string>Evil URL</string>
			<key>CFBundleURLSchemes</key>
			<array>
				<string>malware</string>
			</array>
		</dict>
	</array>

The malware author sticks this app into a DMG and uses the trick mentioned elsewhere in this thread to mount the DMG and then redirect the web page to "malware://anything". Boom - bye bye home directory.

Am I missing something here, or did this vulnerability just get even nastier?

By the way, kampi - the point Charles has been trying to make to you is that your solution to this issue, while admirable in that it's your solution, doesn't actually resolve the issue and remove the vulnerability. Until Apple comes up with a fix, you have two choices - remain vulnerable, or use More Internet, MisFox, or Internet Explorer to change the app for "help" urls to something else. Any of those three apps will work fine, but if you want to remove the vulnerability, you'll have to use one of them.

History lesson - back in the System 7 days, the makers of Interarchy introduced a programming framework called "Internet Config". It's intent was to provide a unified way for apps to know what to do with various types of URLs (like http, mailto, news, etc.). It was very successful, and Apple wound up integrating it into the OS as a part of the Internet Control Panel in System 8. It's still integrated into the OS, and it's still used, but there's no Apple-supplied way of changing its settings in OS X. The three apps mentioned above simply provide an interface to change the settings.

I may have gotten some details wrong, but that's the basic idea.

[kampl]

Originally posted by CharlesS:
It is not a third party security update. It is not not not a security update of any kind. For God's sake. It is a utility to change the frigging helper app settings. It was around before this exploit. It was not designed to patch or otherwise correct this hole as it predates the hole. However, it is nonetheless useful in doing so.


Because I didn't provide a link, because as I said already I can't afford to get slashdotted. Construct the DMG with the instructions I gave above (substituting Help Viewer for Chess) and you will see.

Semantics, hooray. OK, so it is not a security update , you caught the gist of it I would hope. Using this does not mitigate risk wholely, as I assume you understood.

As for the link, I have not derived a dmg from it, as it is stupid to do soo. Yes, everyone should pick up dmg files from anywhere they please. Hmmm, another mitigating strategy. Some sites are allowed, but they are reputable generally and there will be little damage as this is not self propagating nor would a decent worm be written from it that would not require intervention from the end user. Ah well, not a platform killer. Barely a blink really.

Either way, no device I have tried the exploits on are compromised. Maybe you were creative in your coding. I suspect end user intervention is involved to a degree in order to break a device.

Go ahead.......

[itai195]

All the app does (to my knowledge, I used IE to do this...) is let users modify the protocol handler applications on their systems. So it would let you change the help:// handler to something other than the Help Viewer app, effectively providing a workaround. It's not a patch or a security update, just a workaround.

kampl: end user intervention is not required.... If you checked out any demonstrations of the exploit, you'd have noticed that. If you want to ignore this problem that's your prerogative, but it's better to cover your bases IMO.

[Developer]

Originally posted by CharlesS:
I do wonder if this is something we should worry about.

Wow!

Didn't fully believe you and tried it:

- I have no app for feed: protocol which is registered to NetNewsWire 'Nnw*'
- Took a random app (the evil pretender)
- Changed HFS creator code, PkgInfo, and Info.plist to the creator 'Nnw*'
- Pretend to handle CFBunldeURLShemes 'feed' and be Apple default for good measure.

I then mounted my home on another computer which has never before seen this or NetNewsWire, type feed: into Safari and - bang - runs my evil app. I didn't even have to show it in the Finder.

I very much assume this will work with a mounted disk image as well.

[theolein]

Originally posted by Groovy:
RTFA


it is not the exact same thing as this thread has been talking about.
I did paste it here BECAUSE it is related and BECAUSE of the topic you dumb a$$

no disk image needed
no known code on disk needed
no refresh needed


ALL done via javascript. Please show me were this offshoot way was talked about
on the first page of this thread? Unless someone went back and edited their
post it wasn't.


i guess if i paste the link to the "Quicktime:" exploit you will whine about too
as being a RTFT because it is sorta related to the help: exploit lol

Listen, before you call me a dumba$$ and get all upset because I asked you to read the thread, do yourself a favour and actually read the thread. Someone posted exactly the same link you did in this thread a page or so before you did. Call me a duma$$ again in this section of MacNN, and I'll report it and you can look for a new nic, got that?

[utidjian]

Originally posted by kampl:
Stretching? plist files are obviously modified by updates. What was it you were driving at again?

I recall portraying this tripe as a patch, but it is not. It is a third party security update Yeah, there is something I would install in an enterprise.

If you "wrote" an exploit that is available for OS X, that works on my platform? Why is it that it is not working on my up to date platform? I've been through every link here. Nope. Thanks for the variant though.

kampl,

As has been said repeatedly before throughout this the thread, part of the problem is that an untrusted disk image can be mounted by a simple hyperlink. This disk image can contain the Help\ Viewer.app you so carefully removed in your workaround. If you put on your black hat for a moment you could see exactly how this would work and if you were a script kiddy you would be sure to include that app that in your exploit.

What this means is your "fix" is no "fix" at all.

Now... if you really want to be secure from this exploit just remove all web browser apps from your system(s). While you are at it block port 80 at the firewall. Hmmm... I think you will have to remove any email clients also... just to be sure. Also anything that can render HTML. No "third party" in that!

CharlesS has you on this one. Get over it.

[CharlesS]

My God, it works.

I think I've just discovered a new security hole in OS X.

My steps to reproduce this:

1. Fire up XCode and start a new project named "tn3270".

2. Modify the target settings so the app has a creator code of 'GFTM'.

3. Edit Info.plist to add a CFBundleURLType for tn3270:.

4. Build and run.

5. Make a new disk image with Disk Utility.

6. Copy the new app onto the image.

7. Transfer the image using whatever medium you like to another Mac that's never seen the new app you made.

8. Mount the image.

9. Open the mounted image in the Finder using file:///Volumes/whatever in Safari.

10. Type tn3270: in Safari

BANG! We're in!

Brr...

[Spliffdaddy]

You know what's odd?

I'd trust you folks to ensure the security of OSX before I'd trust Apple to do it.

And you aren't even getting paid.

[CharlesS]

I've reported my findings to Apple.

Who would have thought that something good could come from an argument with an asshat on the Internet?

Although, kempl, that isn't saving you from my ignore list. Hope you find the accommodations cozy in there...

[Developer]

I've redirected disk: now as well. And keep the "Open 'safe' files" off.

[CharlesS]

Originally posted by Developer:
I've redirected disk: now as well. And keep the "Open 'safe' files" off.

Now there's a complete and obvious solution. Why didn't I think of that?

Of course. Redirecting disk: will solve the problem. Although it is sad, because I have found remotely mounting images to be very useful in the past, and now I will be forced to lose this functionality until Apple fixes these security holes.

[smeger]

Charles, did you try this with some scheme that's never before been registered? Like "malware" as I suggested above?

I ask because if that works too, this vulnerability doesn't depend on any existing settings on the target machine - it only depends on the target having the "disk" scheme set and nothing more - browse a page and lose your home directory.

[CharlesS]

Originally posted by smeger:
Charles, did you try this with some scheme that's never before been registered? Like "malware" as I suggested above?

I ask because if that works too, this vulnerability doesn't depend on any existing settings on the target machine - it only depends on the target having the "disk" scheme set and nothing more - browse a page and lose your home directory.

Nope, I only tried it with tn3270.

Unfortunately I have some finals I really should be studying for about now, so I don't have any more time for this. Anyone is welcome to try, though. I don't know how much stuff LaunchServices caches when you browse a folder - hopefully it's just stuff like the creator code, bundle ID, etc. If it caches the handled protocols...

[Developer]

Tried it with a phantasy malware: protocol. Works without problems.

[CharlesS]

smeger:

Okay, curiosity got the better of me, so I decided to try it.

IT WORKS.

I created a new app with Xcode, set it up to recognize the "evil:" protocol, gave it a creator code of "eViL" for the simple reason that I think InternetConfig may require one. Next, I transferred it to the other Mac on a disk image, and typed evil: in Safari, and it tried to launch it.

Of course, it didn't get too far, because I forgot to turn ZeroLink off when I built the app (oops). But the fact that it tried proves your hypothesis correct.

Internet Config has got problems!

[theolein]

Originally posted by kampl:
Stretching? plist files are obviously modified by updates. What was it you were driving at again?

I recall portraying this tripe as a patch, but it is not. It is a third party security update Yeah, there is something I would install in an enterprise.

If you "wrote" an exploit that is available for OS X, that works on my platform? Why is it that it is not working on my up to date platform? I've been through every link here. Nope. Thanks for the variant though.

You want to do it your way or the friggin highway? Be our guest: Here's how to do it:

Open the terminal. Do a man on the "defaults" application, specifically wrt "defaults read" and "defaults write". The file you want to modify, the -in your so called *Nix way (real 1337 I must say)- is com.apple.LaunchServices.plist in ~/Library/preferences. You can also modify this file directly using Apple's Property List Editor application (In /Developer/Appplications/Utilities) since you seem to wet yourself anytime anyone mentions a 3rd party application which does exactly this but saves you the hassle of having to find out what the bundle ID's etc are.

[theolein]

Originally posted by smeger:
...

The malware author sticks this app into a DMG and uses the trick mentioned elsewhere in this thread to mount the DMG and then redirect the web page to "malware://anything". Boom - bye bye home directory.

....

I think you should report this to Apple. It just made the whole thing a step more serious. Actually, I thought one of the things Apple was going to have to do to solve this was by disallowing the disk:// protocol altogether, but then again, some malware can just introduce this to the Finder by the above mentioned trick.

[CharlesS]

Originally posted by theolein:
I think you should report this to Apple. It just made the whole thing a step more serious. Actually, I thought one of the things Apple was going to have to do to solve this was by disallowing the disk:// protocol altogether, but then again, some malware can just introduce this to the Finder by the above mentioned trick.

I already did, as soon as I found out that it worked. However, that does not mean that you all shouldn't too! The more reports they get, they more attention they will have to give it.

[CharlesS]

Originally posted by theolein:
You want to do it your way or the friggin highway? Be our guest: Here's how to do it:

Open the terminal. Do a man on the "defaults" application, specifically wrt "defaults read" and "defaults write". The file you want to modify, the -in your so called *Nix way (real 1337 I must say)- is com.apple.LaunchServices.plist in ~/Library/preferences. You can also modify this file directly using Apple's Property List Editor application (In /Developer/Appplications/Utilities) since you seem to wet yourself anytime anyone mentions a 3rd party application which does exactly this but saves you the hassle of having to find out what the bundle ID's etc are.

You'll also need to edit com.apple.internetconfig.plist. This is why it's easier just to use one of the utilities designed to do this!

[theolein]

Originally posted by Developer:
Wow!

Didn't fully believe you and tried it:

- I have no app for feed: protocol which is registered to NetNewsWire 'Nnw*'
- Took a random app (the evil pretender)
- Changed HFS creator code, PkgInfo, and Info.plist to the creator 'Nnw*'
- Pretend to handle CFBunldeURLShemes 'feed' and be Apple default for good measure.

I then mounted my home on another computer which has never before seen this or NetNewsWire, type feed: into Safari and - bang - runs my evil app. I didn't even have to show it in the Finder.

I very much assume this will work with a mounted disk image as well.

I think you should report this as well. It seems, if I understand this correctly, that it doesn't even require the disk:// protocol to work. Can you imagine what havoc malware like this would create in a school or university situation where there are lots of mounted public network shares?

[Simon]

This is becoming a nightmare.

Do these problems maybe also have to do with the fact that Apple is trying to allow browsers to be just too good? I mean, assuming all these helper protocols could only pass a simple URL (only http, not file, ftp, etc.) to an app, would we still have this problem? Why can more than simple URLs be sent from a browser to an app? Could the problem be solved by breaking this functionality?

Of course I don't doubt passing more than URLs to other apps can be useful, but since it also has the potential to allow such malicious exploits wouldn't it be better if Apple simply breaks it?

[CharlesS]

My vote for a fix is to allow Internet Config only to launch apps on a local hard drive. If it's on a removable disk, or on a network share, or on a disk image - don't mount it!

The problem seems to be caused by LaunchServices caching apps' URL helper abilities. Perhaps that's a bad idea; maybe one should have to set up an app explicitly in Internet Config before a URL would launch it.

[theolein]

Originally posted by CharlesS:
I already did, as soon as I found out that it worked. However, that does not mean that you all shouldn't too! The more reports they get, they more attention they will have to give it.

Am I understanding this correctly?: According to Developer the malware (with the malware:// protocol) does not need to be in a disk image, nor does it need to be browsed by the Finder, but only has to be mounted in order for this exploit to be carried out?

[smeger]

Originally posted by Simon:
Do these problems maybe also have to do with the fact that Apple is trying to allow browsers to be just too good? I mean, assuming all these helper protocols could only pass a simple URL (only http, not file, ftp, etc.) to an app, would we still have this problem? Why can more than simple URLs be sent from a browser to an app? Could the problem be solved by breaking this functionality?

The method I posted above doesn't require any URL to be passed - the malicious webpage can just redirect to evil://blah and the malware will be launched.

What's a good email address to submit this to at Apple? Or is it better for me to use my developer account to submit it as a bug report?

[CharlesS]

Originally posted by theolein:
Am I understanding this correctly?: According to Developer the malware (with the malware:// protocol) does not need to be in a disk image, nor does it need to be browsed by the Finder, but only has to be mounted in order for this exploit to be carried out?

In my experience, and according to my understanding of LaunchServices, it should need to be browsed by the Finder. Other than that, all bets are off. If you can get it in the file system, and you can get it to show up in a Finder window, you're in.

[CharlesS]

Originally posted by smeger:
The method I posted above doesn't require any URL to be passed - the malicious webpage can just redirect to evil://blah and the malware will be launched.

What's a good email address to submit this to at Apple? Or is it better for me to use my developer account to submit it as a bug report?

The e-mail that was posted early on in this thread was:

[email protected]

I've sent several reports to this e-mail address.

[theolein]

Originally posted by smeger:
The method I posted above doesn't require any URL to be passed - the malicious webpage can just redirect to evil://blah and the malware will be launched.

What's a good email address to submit this to at Apple? Or is it better for me to use my developer account to submit it as a bug report?

JLL posted this a while back: [email protected]

[Developer]

Originally posted by CharlesS:
In my experience, and according to my understanding of LaunchServices, it should need to be browsed by the Finder.

It didn't need that. I just mounted my home folder without opening it and LaunchServices found the new app that advertised the new protocol.

[theolein]

Originally posted by CharlesS:
In my experience, and according to my understanding of LaunchServices, it should need to be browsed by the Finder. Other than that, all bets are off. If you can get it in the file system, and you can get it to show up in a Finder window, you're in.

If I had another Mac up and running at the moment I would test this, but I think Developer specifically mentioned that it did not even require the Finder to browse it (see it), I assume that is because all mounted network shares automatically show up in the finder.

Christ, this is serious. Really shocking.

[CharlesS]

On second thought, it would probably fix this if LaunchServices were to only register an app as a helper for a protocol when it was launched. Is there any real reason why it has to be cached when it is browsed to?

I don't think IC worked the present way in OS 9. There, I think that an app had to launch before it could register in IC.

[CharlesS]

Originally posted by Developer:
It didn't need that. I just mounted my home folder without opening it and LaunchServices found the new app that advertised the new protocol.

Hmm, maybe things are different with network shares. With a .dmg, it didn't work for me until I browsed to it.

[theolein]

Originally posted by CharlesS:
On second thought, it would probably fix this if LaunchServices were to only register an app as a helper for a protocol when it was launched. Is there any real reason why it has to be cached when it is browsed to?

I don't think IC worked the present way in OS 9. There, I think that an app had to launch before it could register in IC.

I wonder if it wouldn't be best if Apple added a security layer to InternetConfig, in that any changes had to be confirmed with an admin password?

[Simon]

Yikes, malware://blah works.

New suggestion:

How about IC only knows Apple's defaults. From then on when you launch a new app that offers to be a helper for a certain protocol, IC pops up a dialog and tells you that the app "foo" could be a helper for the protocol "bar" and asks for permission to set it. You could then allow this by typing your admin password. No more automatic protocol settings.

However, since Help Viewer is part of the system and default installed, I acknowledge that the above solution wouldn't prevent the original exploit. Apple would still need to fix Help Viewer and check all their default helper apps for such holes.

This is very scary. Damn! Some people at Apple need to get off their asses and into gear really quickly.

[Developer]

Originally posted by CharlesS:
On second thought, it would probably fix this if LaunchServices were to only register an app as a helper for a protocol when it was launched.

This is how I thought it worked. If it only registered apps explicitly double-clicked by the user and installed in Applications this wouldn't be a problem. It's as if someone made LaunchServices too smart.

[itai195]

Originally posted by theolein:
I wonder if it wouldn't be best if Apple added a security layer to InternetConfig, in that any changes had to be confirmed with an admin password?

Or just ask for a password whenever InternetConfig launches a non-local protocol handler for the first time... Or let those programs run with very limited privileges.

[CharlesS]

Originally posted by Simon:
Yikes, malware://bla works.

New suggestion:

How about IC only knows Apple's defaults. From then on when you launch a new app that offers to be a helper for a certain protocol, IC pops up a dialog and tells you that the app "foo" could be a helper for the protocol "bar" and asks for permission to set it. You could then allow this by typing your admin password. No more automatic protocol settings.

Seems to me once you've launched it once, it's had all the opportunity it needs to do whatever harm it wants. No need to make it launch with an evil:// URL in this case. So I don't think it should be a big issue, as long as the apps have to actually be launched before they will get their protocols registered. Registering them when browsing is not acceptable.