[CharlesS]

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

Well LaunchServices/Desktop DB always cached a file's creator code when browsing, all the way back to the beginning. This makes sense, but it seems that when LS got integrated with Internet Config, it started caching some stuff that it should not be caching when browsing.

I am still shocked; I did not expect that to work. I thought that it would be necessary to give an app the creator code of a non-existent helper app (which would still have been a problem).

[utidjian]

Originally posted by CharlesS:
Well LaunchServices/Desktop DB always cached a file's creator code when browsing, all the way back to the beginning. This makes sense, but it seems that when LS got integrated with Internet Config, it started caching some stuff that it should not be caching when browsing.

I am still shocked; I did not expect that to work. I thought that it would be necessary to give an app the creator code of a non-existent helper app (which would still have been a problem).

Just a thought...

But perhaps this is a basic problem with how HFS+ works?

It is late and I am not thinking all that clearly but it occured to me to ask myself... Why aren't other Unixes affected by this problem? I think it is mainly because a Unix user has a specific $PATH for executables and a regular user can't just mount any old disk image or share over the network.
Does that make sense at all?
Will Apple have to abandon or re-think how HFS+ works?

I haven't thought too much about the automatic registration of arbitrary protocols... not sure that would be a problem for other Unixes.

Thanks for all the brainstorming that you and others have done on this. Good luck on your finals (I have some also).

[CharlesS]

Originally posted by utidjian:
Just a thought...

But perhaps this is a basic problem with how HFS+ works?

It is late and I am not thinking all that clearly but it occured to me to ask myself... Why aren't other Unixes affected by this problem? I think it is mainly because a Unix user has a specific $PATH for executables and a regular user can't just mount any old disk image or share over the network.
Does that make sense at all?
Will Apple have to abandon or re-think how HFS+ works?

I haven't thought too much about the automatic registration of arbitrary protocols... not sure that would be a problem for other Unixes.

Thanks for all the brainstorming that you and others have done on this. Good luck on your finals (I have some also).

HFS+ by itself only stores a type and creator code, and some metadata. The first problem I pointed out (giving an app a creator code which is the same as a non-existent helper app) is indeed partially the fault of HFS+ (but more significantly the fault of including non-existent helper apps in the default settings!). The caching of helper protocols is just a nasty LaunchServices misfeature and doesn't have much to do with HFS+.

God, I really have to finish my studying! What am I doing posting here?! I'm going to shut my computer down for the night; maybe that will get me to quit coming back. See you all later...

[theolein]

I just tried sudo chown'ing com.apple.internetconfig.plist and com.apple.LaunchServices.plist to root:wheel. Worked fine. I assumed, that, if they were owned by root and had 600 set, that System Preferences, which runs as the user, would not be able to modify them (MoreInternet specifically). WRONG!, MoreInternet happily allows one to change a protocol helper and it actually (or Sys Prefs, I don't know which) changes both those files back to owner:owner!

Am I dreaming or is this just totally wrong? I can't modify those files in the terminal without su'ing or using sudo, but Sys Prefs, running as owner happily does it!

[smeger]

Okay, I've written a test exploit that uses the new url-registration idea. I tested it out, got everything together, and then moved to my girlfriend's computer that had never seen any of this stuff before and surfed to my test page. With no further user intervention, my test exploit wrote a file into her home directory and could just as easily have erased her home directory. The whole thing took me about 15 minutes to code.

This doesn't use the "help" url handler at all, it depends only upon the "disk" handler.

I'll be reporting this to apple as soon as I can figure out how to do so.

[theolein]

Originally posted by smeger:
Okay, I've written a test exploit that uses the new url-registration idea. I tested it out, got everything together, and then moved to my girlfriend's computer that had never seen any of this stuff before and surfed to my test page. With no further user intervention, my test exploit wrote a file into her home directory and could just as easily have erased her home directory. The whole thing took me about 15 minutes to code.

This doesn't use the "help" url handler at all, it depends only upon the "disk" handler.

I'll be reporting this to apple as soon as I can figure out how to do so.

If you perhaps missed it, here's the security reporting mail address again: [email protected]

[smeger]

Thanks theolin, I did miss it. I'm reporting this there and via RadarWeb.

[theolein]

Originally posted by theolein:
I just tried sudo chown'ing com.apple.internetconfig.plist and com.apple.LaunchServices.plist to root:wheel. Worked fine. I assumed, that, if they were owned by root and had 600 set, that System Preferences, which runs as the user, would not be able to modify them (MoreInternet specifically). WRONG!, MoreInternet happily allows one to change a protocol helper and it actually (or Sys Prefs, I don't know which) changes both those files back to owner:owner!

Am I dreaming or is this just totally wrong? I can't modify those files in the terminal without su'ing or using sudo, but Sys Prefs, running as owner happily does it!

Replying to my own post here:

Got it to work:
1. sudo chown root:wheel com.apple.LaunchServices.plist
2. sudo chown root:wheel com.apple.internetconfig.plist
3. sudo chflags schg com.apple.LaunchServices.plist
4. sudo chflags schg com.apple.internetconfig.plist

Now nothing apart from root can alter those two files. It's a lame arse workaround but the steps would be, at this point in time:

1. Change the help:// protocol helper to point to chess in Explorer or MoreInternet or MisFox.
2. Do the same for the disk:// protocol helper.
3. Do the steps mentioned above. (change them to being owned by root and set the system change flag so that only the super user can change the files)

Nothing apart from root nothing can now change the files, meaning that no malware can introduce a remote vulnerability.

If you're worried that it might screw up your system, doing the following will set everything back to the way it was, (a good idea before you download Apple's next security update, but that might take a while, considering the gravity of this problem):

1. sudo chown youruser:youruser com.apple.LaunchServices.plist
2. sudo chown youruser:youruser com.apple.internetconfig.plist
3. sudo chflags noschg com.apple.LaunchServices.plist
4. sudo chflags noschg com.apple.internetconfig.plist


edit:Do NOT do this. It can seriously mess with the FS. Had to boot into single user mode to fix this!

[CharlesS]

I have no self-control at all and am posting again.

Theolein, I don't think changing the permissions of those files will do any good. When I tried the exploit with the evil: protocol, afterwards I couldn't find evil: anywhere in the setting files. I don't think it actually sets those; I think it just caches it as an app it can use if it doesn't have any particular helper set for a protocol. And besides, as you pointed out, Internet Config (which More Internet is most likely using to change the settings) seems able to change them even if they are owned by root, so if the system were to want to change these files, it would likely be able to do so anyway.

[theolein]

Bugs galore! I just dragged the above text to the desktop in order to have a clipping that so I would not forget to set everything back to normal when Apple provides a security update. I double clicked on the clipping and Property List Editor started up and opened both the above mentioned files!

Since when did the finder pass (and parse) terminal commands or file names in text clippings?

[CharlesS]

Originally posted by theolein:
Bugs galore! I just dragged the above text to the desktop in order to have a clipping that so I would not forget to set everything back to normal when Apple provides a security update. I double clicked on the clipping and Property List Editor started up and opened both the above mentioned files!

Since when did the finder pass (and parse) terminal commands or file names in text clippings?

Are you sure you didn't already have those files selected in the Finder? Doing this did nothing for me except what is expected.

[theolein]

Originally posted by CharlesS:
Are you sure you didn't already have those files selected in the Finder? Doing this did nothing for me except what is expected.

You're right, I had them under a Finder window, and selected.

Back to the main topic: Changing the flags to schg does prevent MoreInternet from changing the files, but I have no idea if the cahing makes it all redundant. Could you perhaps provide me with a link to your evil:// malware app so I can test it with those settings?

[CharlesS]

Originally posted by theolein:
You're right, I had them under a Finder window, and selected.

Back to the main topic: Changing the flags to schg does prevent MoreInternet from changing the files, but I have no idea if the cahing makes it all redundant. Could you perhaps provide me with a link to your evil:// malware app so I can test it with those settings?

I could e-mail it to you. What's your address?

[theolein]

Originally posted by CharlesS:
I could e-mail it to you. What's your address?

I'll PM it to you.

[smeger]

Relief is here

We've whipped up a quick haxie that watches for non-standard scheme handlers and prompts you before allowing them to load. This isn't intended to be a long-term fix, but it should keep people safe until Apple actually fixes things.

To protect yourself, grab Paranoid Android, install it, and follow the prompts. Once you've done this, any non-standard URL will make Paranoid Android pop up a message showing you the URL and asking your permission to proceed.

More info is available at the Paranoid Android site.

Paranoid Android is completely free - we did this simply for the benefit of the Mac community.

[Diggory Laycock]

Wow - this thread has got a bit busy over-night.

Changing the permissions on the internetconfig.plist (or editing by hand) will not work - because any changes to internetConfig are does through an API - so the system changes the file.

The 'new protocol' problem is scary.

[Simon]

Originally posted by smeger:
Relief is here
...
Paranoid Android is completely free - we did this simply for the benefit of the Mac community.

Relief would be if it didn't require APE.

APE has caused so much trouble for so many people it should be forbidden.

I would have really liked to try PA, but I wouldn't let APE near any of my administered Macs.

[GENERAL_SMILEY]

Originally posted by smeger:
Relief is here

We've whipped up a quick haxie that watches for non-standard scheme handlers and prompts you before allowing them to load. This isn't intended to be a long-term fix, but it should keep people safe until Apple actually fixes things.

To protect yourself, grab Paranoid Android, install it, and follow the prompts. Once you've done this, any non-standard URL will make Paranoid Android pop up a message showing you the URL and asking your permission to proceed.

More info is available at the Paranoid Android site.

Paranoid Android is completely free - we did this simply for the benefit of the Mac community.

Ooh clever. Will try it.

The main problem I have with APE is the icon, it bothers me for some reason.

[sniffer]

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?

Agree, it's not mass-deployable. But here is the dilemma. Apple should have done something here for a long time ago, but haven't reacted. That's why this is leaked to the public in the first place. Hopefully Apple will come out with a fix ASAP. They are the one that should get a mass-deployable fix on the table.

[Rosyna]

Originally posted by Simon:
Relief would be if it didn't require APE.

APE has caused so much trouble for so many people it should be forbidden.

I would have really liked to try PA, but I wouldn't let APE near any of my administered Macs.

Sorry hun, you are mistaken. Some APEs have causes problems for people. In 3 years or whatever, APE itself has had ONE bug that only affected 10.1.5.

It is amusing your stubbornness would allow an exploit to go unfixed is all I'm saying.

[turtle777]

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

[email protected]

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

You guys,

I'd really like to report this stuff to Apple, but I understand only half of the stuff going on here.

Could someone of you post a summary of the problem that can be used to be emailed to Apple.[/

Then, even a clueless concerned user like me can notify Apple by cut & paste

Thanks,
-t

[sniffer]

Originally posted by smeger:
Relief is here

We've whipped up a quick haxie that watches for non-standard scheme handlers and prompts you before allowing them to load. This isn't intended to be a long-term fix, but it should keep people safe until Apple actually fixes things.

It looks very good. Just tested it. But what exactly is the standard or non-standard scheme handlers here? Does it mean it's designed to only allow FTP, HTTP and SHTTP by default then?

[SMacTech]

Originally posted by Rosyna:
Sorry hun, you are mistaken. Some APEs have causes problems for people. In 3 years or whatever, APE itself has had ONE bug that only affected 10.1.5.

It is amusing your stubbornness would allow an exploit to go unfixed is all I'm saying.

His stubbornness is well founded IME. There are other ways around this security issue than installing APE and causing other issues as well. APE may work for you in your setup, but as an admin of many OS X computers, it is on the forbidden list here.

[biscuit]

So, lemme get this straight in my head,

• A disk image can be remotely mounted with a click via the use of disk://, or d'loaded and mounted via Safari's "Open 'Safe' files..." pref
• Said disk image can be opened without user-intervention via the use of file://
• The disk image can contain an app that handles a new URL scheme, e.g. evil://
• LaunchServices will, without notification or intervention, register said URL scheme
• A refresh-tag in a web-site can call the new URL scheme without user-intervention, thus launching the app on the DMG. This app is now free to wreak havoc.
• OR the nasty app can just pretend to be one of the non-installed programs found in IC and achieve the same result.

So, Paranoid Android will save us from the new URL schemes, but what about the ones that are assigned to non-installed apps? Change them all to Chess with More Internet? And even with PA installed, I take it we still have to keep help:// away from Help Viewer.app? And probably disk:// should point to Chess too, right?

Maybe there's a reason Apple didn't respond quickly to the original exploit i.e., they found this mess themselves and are trying to find an elegant (and robust) solution?

biscuit

[sniffer]

Originally posted by biscuit:

So, Paranoid Android will save us from the new URL schemes, but what about the ones that are assigned to non-installed apps?

I just tested the Paranoid Android solution. Originally I have the help protocol attached to Chess.app. So every time I type something like "help:runscript=blahblah" Chess.app will start. But with PA enabled, all a get a pop-up like this.


I'll assume it means it blocks everything except standard protocols like http, etc. But I don't know what smeger meant with "non-standard scheme handlers" yet.

Edit: I tested it with the strange tn3270 protocol which is not attached to any applications, and PA worked flawlessly there as well.

[biscuit]

OK, that's good news, thanks sniffer. So actually, we could put all the URL handlers back to rights as long as PA is running. Not sure I want to do that though...

biscuit

[sniffer]

Originally posted by biscuit:
OK, that's good news, thanks sniffer. So actually, we could put all the URL handlers back to rights as long as PA is running. Not sure I want to do that though...

Agree to that. At least until Apple have the patch. It's a extra relief to know that even if you accidentally click the allow button once, you'll still be safe*. I'll not switch back the URL handle for the help protocol as things stands now. No way.

*[edit:] Ops, speculative assumption. This hole might get exploited in one accidentally click on the allow button anyway if i.e. protocols that is not assigned with an app gets one trough Launch Service when an app get downloaded and automatically unzipped on your desktop. Ugh.. This is confusing.

[theolein]

Originally posted by biscuit:
So, lemme get this straight in my head,

• A disk image can be remotely mounted with a click via the use of disk://, or d'loaded and mounted via Safari's "Open 'Safe' files..." pref
• Said disk image can be opened without user-intervention via the use of file://
• The disk image can contain an app that handles a new URL scheme, e.g. evil://
• LaunchServices will, without notification or intervention, register said URL scheme
• A refresh-tag in a web-site can call the new URL scheme without user-intervention, thus launching the app on the DMG. This app is now free to wreak havoc.
• OR the nasty app can just pretend to be one of the non-installed programs found in IC and achieve the same result.

So, Paranoid Android will save us from the new URL schemes, but what about the ones that are assigned to non-installed apps? Change them all to Chess with More Internet? And even with PA installed, I take it we still have to keep help:// away from Help Viewer.app? And probably disk:// should point to Chess too, right?

Maybe there's a reason Apple didn't respond quickly to the original exploit i.e., they found this mess themselves and are trying to find an elegant (and robust) solution?

biscuit

I think it's a bit more complicated than that. As I see at the moment:
The original problem had three parts:

• The help:// protocol could be used to launch any Applescript anywhere on the disk. (Such as the OpnApp.scpt that is all over the disk)
• The disk:// protocol could be used to force a browser to remotely, without downloading, mount a disk image, thereby giving the above problem a known path to launch an applictaion on the disk image.
• Via meta refresh tags or Javascript, the process could be done transparently in the background without the user having to click on a link. The simple visiting of a mailcious webpage would be enough.

However, the problem then got worse in that CharlesS, Developer and Smeger amongst others discovered that the actual problem is deeper than that:

• Apple LaunchServices, the API that sets which protocol helpers are bound to which applications will automatically add a new protocol helper for any application that has the relevant information in it's Info.plist etc. This means that if one browses a mounted disk image with said malicious application, a webpage that uses the new protocol added by that application will automatically launch that application.
• Apple LaunchServices will also, as Developer has noted, automatically add a new protocol and helper for the same application as mentioned above if a network share is mounted. This has consequences, I think, for schools, companies and universities, that rountinely have mounted public shares and lots of untrusted/unknowing users.
• If the "Open 'safe' files after downloading" option is checked in Safari preferences (default) then, principally any archive type can be downloaded and automatically expanded and provide a known path (The Desktop is default in Safari) to a malicious application.
• If the "Automatically decode 'Macbinary/BinHex' files after downloading" options in Internet Explorer is checked (deafult), then, principally any archive type can be downloaded and automatically expanded and provide a known path (The Desktop is default) to a malicious application.
• If the "Open it with the default application" radio button is checked (default) in Mozilla/Netscape's download dialog, then , principally any archive type can be downloaded and automatically expanded and provide a known path (The Desktop is default) to a malicious application.

The temporary workarounds at the moment are to use Internet Explorer, MoreIneternet or MisFox to point:

• the "help" protocol helper to an innocuous application, such as chess, and
• to add a "disk" protocol helper with one of those applications and point it to the same innocuous application, such as chess, and
• Uncheck the "Open 'safe' files after downloading" option in Safari preferences.
• Uncheck the "Automatically decode 'Macbinary/BinHex' files after downloading" options in Internet Explorer.
• Check the "Save it to disk" radio button in Mozilla/Netscape's download dialog.

The temporary workarounds to do not help with the deeper problem of LaunchServices adding protocol helpers with no checks or guards, but those are slightly less likely to be abused.


If I missed anything or misstated anything, would someone please correct me.

Edit: Changed according to CharlesS' suggestions. (Someone else will have to test Camino, Firefox and the Opera 7.5 public beta)

[biscuit]

Originally posted by theolein:
I think it's a bit more complicated than that. As I see at the moment:
snip

Thanks theolin, great summary. I'd overlooked the extra-scary JavaScript variety of execution. I'd say your post is the ideal thing for us all to send to Apple (with your permission).

So, really, Paranoid Android is the most complete solution but involves installing APE, which it seems some peeps aren't keen on doing. Maybe someone could write a stand-alone version a la Little Snitch?

biscuit

[theolein]

Originally posted by biscuit:
Thanks theolin, great summary. I'd overlooked the extra-scary JavaScript variety of execution. I'd say your post is the ideal thing for us all to send to Apple (with your permission).

So, really, Paranoid Android is the most complete solution but involves installing APE, which it seems some peeps aren't keen on doing. Maybe someone could write a stand-alone version a la Little Snitch?

biscuit

Of course you may post away. I'm sort of the opinion that anything that gets said in a public forum may be quoted anywhere, but I might be wrong there. I'm also not going to install PA, because I really don't want too many system extras doing their thing on my system. Having too many extra doodahs tends to make any OS go wonky after a while, so I prefer to keep it as simple as possible. That said, I think PA is the best approach at the moment until Apple sorts this out.

[CharlesS]

Originally posted by theolein:
The temporary workarounds at the moment are to use Internet Explorer, MoreIneternet or MisFox to point:

• the "help" protocol helper to an innocuous application, such as chess, and
• to add a "disk" protocol helper with one of those applications and point it to the same innocuous application, such as chess.

The temporary workarounds to do not help with the deeper problem of LaunchServices adding protocol helpers with no checks or guards, but those are slightly less likely to be abused.


If I missed anything or misstated anything, would someone please correct me.

You missed a critical part of the workaround. You must not only remap help: and disk:, but you must also turn 'safe' files off in Safari's Preferences.

I've been thinking about this a little more, and I've realized that with the evil:// protocol attack, you could use a plain old .zip or .sit rather than a .dmg. Since items on the Desktop are always visible and show up immediately after being downloaded in Safari, there's a chance that automatically expanding one of those could cause it to get picked up by LaunchServices. Then, evil://whatever and bang, you're in. So the thing is to turn off 'safe' files as well as the disk: and help: protocols.

edit: Is anyone interested in hosting the archive holding the exploit apps that I made, so we can have a public demonstration available? I cannot afford to have my site slashdotted at the moment, and my university's network has enough problems right now that I think I shouldn't risk causing them more by putting it on my account with them either...

[biscuit]

Originally posted by CharlesS:
I've been thinking about this a little more, and I've realized that with the evil:// protocol attack, you could use a plain old .zip or .sit rather than a .dmg...

Oh me oh my, it just gets better and better

biscuit

[turtle777]

Originally posted by theolein:
I think it's a bit more complicated than that. As I see at the moment:
The original problem had three parts:
(snip)
If I missed anything or misstated anything, would someone please correct me.

Vielen Dank, theolein.

I just sent of an email to Apple.

I'm thinking of sending the same email every other day.
Just to get on their nerves, so they get their heads out their a$$.

-t

[sniffer]

Originally posted by CharlesS:

edit: Is anyone interested in hosting the archive holding the exploit apps that I made, so we can have a public demonstration available? I cannot afford to have my site slashdotted at the moment, and my university's network has enough problems right now that I think I shouldn't risk causing them more by putting it on my account with them either...

If someone just could upload it to their iDisk, it should be good. There is about no bandwidth limit on .Mac, or so it seems.

[negativeSpace]

Originally posted by biscuit:
So, really, Paranoid Android is the most complete solution but involves installing APE, which it seems some peeps aren't keen on doing. Maybe someone could write a stand-alone version a la Little Snitch?

biscuit

But little snitch installs a kernel extension which has a greater chance of crashing your system than APE does, so given the choice, I would definately go with .ape's.

[theolein]

Originally posted by CharlesS:
You missed a critical part of the workaround. You must not only remap help: and disk:, but you must also turn 'safe' files off in Safari's Preferences.

I've been thinking about this a little more, and I've realized that with the evil:// protocol attack, you could use a plain old .zip or .sit rather than a .dmg. Since items on the Desktop are always visible and show up immediately after being downloaded in Safari, there's a chance that automatically expanding one of those could cause it to get picked up by LaunchServices. Then, evil://whatever and bang, you're in. So the thing is to turn off 'safe' files as well as the disk: and help: protocols.

...

I've modified my note further up, and expanded it to include some other browsers.

[Dale Sorel]

I just tried the haxie fix, and it seems to work

[smeger]

Originally posted by sniffer:
It looks very good. Just tested it. But what exactly is the standard or non-standard scheme handlers here? Does it mean it's designed to only allow FTP, HTTP and SHTTP by default then?

It lets through 'http', 'ftp', 'mailto', 'file', and 'itms' without prompting the user. For everything else, it waits for you to confirm or cancel first. I should probably add 'shttp' to that list.

[sniffer]

Originally posted by smeger:
It lets through 'http', 'ftp', 'mailto', 'file', and 'itms' without prompting the user. For everything else, it waits for you to confirm or cancel first. I should probably add 'shttp' to that list.

Sounds good to me. Thanks a million!

edit: one more thing. When you click "Allow", it means "Allow once" right (I hope)?

[smeger]

Originally posted by biscuit:
So, lemme get this straight in my head,

• A disk image can be remotely mounted with a click via the use of disk://, or d'loaded and mounted via Safari's "Open 'Safe' files..." pref
• Said disk image can be opened without user-intervention via the use of file://
• The disk image can contain an app that handles a new URL scheme, e.g. evil://
• LaunchServices will, without notification or intervention, register said URL scheme
• A refresh-tag in a web-site can call the new URL scheme without user-intervention, thus launching the app on the DMG. This app is now free to wreak havoc.
• OR the nasty app can just pretend to be one of the non-installed programs found in IC and achieve the same result.

So, Paranoid Android will save us from the new URL schemes, but what about the ones that are assigned to non-installed apps? Change them all to Chess with More Internet? And even with PA installed, I take it we still have to keep help:// away from Help Viewer.app? And probably disk:// should point to Chess too, right?

Maybe there's a reason Apple didn't respond quickly to the original exploit i.e., they found this mess themselves and are trying to find an elegant (and robust) solution?

biscuit

biscuit, this is almost correct. Here's my slightly revised list:

• A disk image can be remotely mounted with a click via the use of disk://
• The disk image is automatically mounted regardless of the setting of Safari's "Open Safe Files" preference
• The disk image can contain an app that handles a new URL scheme, e.g. evil://
• LaunchServices will, without notification or intervention, register said URL scheme
• A refresh-tag in a web-site can call the new URL scheme without user-intervention, thus launching the app on the DMG. This app is now free to wreak havoc.
• OR the nasty app can just pretend to be one of the non-installed programs found in IC and achieve the same result.

Paranoid Android will block all url schemes except for 'http', 'ftp', 'mailto', 'file', and 'itms' until the user provides the okay. This means that it provides protection against all known variants of this vulnerability - Help viewer, scripts, using Chess, etc.

[theolein]

Originally posted by smeger:
It lets through 'http', 'ftp', 'mailto', 'file', and 'itms' without prompting the user. For everything else, it waits for you to confirm or cancel first. I should probably add 'shttp' to that list.

You mean https, don't you?

[turtle777]

Originally posted by theolein:
You mean https, don't you?

Yes, that should be included.

Don't want to be constantly clicking when doing any banking or secure transactions...

Besides that:

-t

[Groovy]

Originally posted by itai195:
The link was already posted and already discussed within this thread.

it was updated since then. (and again since your post)
that was the whole point of re linking to it.

geez do you think the info that is learned is static?


within 4 or 5 days help: disk: and Quicktime: have all found exploits that need
to be gone back to for anyone that read the pages the first day and thinks that
is all there is and the original fixes are still keeping them safe when they are not.


if that page finds ANOTHER major exploit i will link to is AGAIN so be ready

[CharlesS]

Originally posted by Groovy:
it was updated since then. (and again since your post)
that was the whole point of re linking to it.

geez do you think the info that is learned is static?


within 4 or 5 days help: disk: and Quicktime: have all found exploits that need
to be gone back to for anyone that read the pages the first day and thinks that
is all there is and the original fixes are still keeping them safe when they are not.


if that page finds ANOTHER major exploit i will link to is AGAIN so be ready

Quicktime:? I haven't heard of this one. What have they been able to do with it?

[Groovy]

Originally posted by theolein:
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?

I did. and the page was updated since the link was first posted.


Get now?


Oh and plan to post the link again every time it is updated
with worthy data so get off your high horse.

[theolein]

Originally posted by CharlesS:
Quicktime:? I haven't heard of this one. What have they been able to do with it?

quicktime://, QuickTime://, Quicktime://, mov:// and movie:// all do nothing as far as I can see.

[sniffer]

Well, I most definitive hope this is the last time we'll have to worry about security exploits this way. This should be handled by the people in charge, and not by the community. This is not what you should expect on the Mac platform.
Still, taking it public was the right thing to do. Hopefully this will be the last time such measures will be necessary. It's a insane thing to do when you think about it.

[Groovy]

Originally posted by smeger:
Relief is here

We've whipped up a quick haxie that watches for non-standard scheme handlers and prompts you before allowing them to load. This isn't intended to be a long-term fix, but it should keep people safe until Apple actually fixes things.

To protect yourself, grab Paranoid Android, install it, and follow the prompts. Once you've done this, any non-standard URL will make Paranoid Android pop up a message showing you the URL and asking your permission to proceed.

More info is available at the Paranoid Android site.

Paranoid Android is completely free - we did this simply for the benefit of the Mac community.

I see you said non standard. What about the non standards ones already added.
example I added hotline: and a few others. It will not flag those right?

I'm about to DL and test it now and see for myself but I figured I would ask

[[APi]TheMan]

Originally posted by CharlesS:
Quicktime:? I haven't heard of this one. What have they been able to do with it?

I think he's talking about the QuickTime remote heap overflow released May 2nd that was patched in QuickTime 6.5.1.

[sjk]

Originally posted by theolein:
1. Change the help:// protocol helper to point to chess in Explorer or MoreInternet or MisFox.

In case no one's already mentioned it, RCDefaultApp has a "<disable>" option for associating different URL schemes with a DoNothing app.