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

[smeger]

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

Paranoid Android lets 'http', 'ftp', 'mailto', 'file', and 'itms' schemes through transparently and prompts the user for everything else.

Some random person has a nice writeup with a pic of Paranoid Android in action here.

[smeger]

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

That's correct. It wouldn't be very worthwhile otherwise.

[sniffer]

smeger, the security flaw also exists in 10.2.8 as far as I know, and it appears that Paranoid Android doesn't work in Jaguar. I only have Panther installed so I can't verify this, so I am asking on behalf of someone else, will Paranoid Android also support Jaguar? Thanks again.

[smeger]

Originally posted by sniffer:
smeger, the security flaw also exists in 10.2.8 as far as I know, and it appears that Paranoid Android doesn't work in Jaguar. I only have Panther installed so I can't verify this, so I am asking on behalf of someone else, will Paranoid Android also support Jaguar? Thanks again.

I made Paranoid Android 10.3 only because my test exploit using the malware: handler didn't work in 10.2. But it appears that other variants of the exploit do work in Jag, so I've removed the Panther-only for the next release. I'm gonna hang back for another 12 hours or so to see if anything else comes up that needs fixing and then release an updated version.

[sniffer]

Originally posted by smeger:
I'm gonna hang back for another 12 hours or so to see if anything else comes up that needs fixing and then release an updated version.

Sounds reasonable*. Once again, thanks for the update so far.

* I have no idea what the author is talking about in the link, but you never know anything for sure under these circumstances.

[edit: The author of the linked page has updated the info, so what ever the page said earlier it's not valid anymore. Hmm.]

[alcatholic]

Telnet: protocol can also be used as an exploit. Haven't seen anymore info on the quicktime: exploit.

Here's the link:
Jay Allen's Blog

Jay Allen also linked to a letter by a Peter da Silva blaming apple for too tightly integrating trusted and untrusted namespaces:
Peter da Silva's Letter to Apple

This has been quite exciting. Watching a huge security hole, evil: protocol, get discovered right in this thread by Developer, Smeger, Charles S, et al. Charles line was a classic "aha" moment:

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

Funny how Kampl stopped posting. Maybe he finally got it and realized he better start changing protocol handles for all the users in his corporate environment "core OS's"...sounded like he didn't understand the "mythical, magical Launchservices" until all of you started spelling out the new exploits that didn't involve help:

Anyway, time to go safeguard my relatives' computers.

[Hugin777]

As no one has posted a link (to the new exploit) yet, here goes:

Security check

NOTE: There's no automatic redirection or anything, just click the links to perform each step in turn.

PS: OpnAppFixer is just the name of the directory - I'm not fixing anything . . .

Edit: added "(to the new exploit)"

[utidjian]

Well... (in the true Mac spirit) some more speculation:

I am wondering if the reason why Apple hasn't issued an update yet is because this is a really deep bug/feature of Mac OS X. From what I can determine from all the hullabaloo is that it is really several features of Mac OS X, intentionally designed the way they are, that, when combined, create this hole. In order to fix it and fix it good Apple has to make some pretty fundamental changes to the system and how applications interact.

As we have been discovering the problem is not simple. As, more or less, ordinary Mac users we don't have the resources and understanding that Apple has of this problem. As an illustration... when the hole was first announced here (last Friday) there has been much speculation/expermintation/testing/and discovery of new aspects of the hole. There may be much more to it than we have discovered so far. There is almost certainly some deep implications on what has been discovered.

If Apple has known about this for very near 3 months it is too horrible to think that they overlooked or dismissed it. I imagine that they have been working pretty much flat out to fix this problem for that length of time. Apple has certainly been working on it for the past week. Yet we still don't have a fix.

My guess is Apple is trying to fix the problem with minimal impact on functionality and overall ease of use... trying not to alter too drastically what we are used to. Because of this I think we shall see the fix(es) to this problem come out in stages.

In the end... I think it will be a good thing for us users and for Apple. Many of us have been far too complacent about Mac OS X security (including myself) since it has been out. Though I still feel rather strongly that Apple has to change its policy of silence during the discovery-to-fix window in time that a bug is known about.

Thoughts?

[Hugin777]

Originally posted by utidjian:
I am wondering if the reason why Apple hasn't issued an update yet is because this is a really deep bug/feature of Mac OS X. From what I can determine from all the hullabaloo is that it is really several features of Mac OS X, intentionally designed the way they are, that, when combined, create this hole. In order to fix it and fix it good Apple has to make some pretty fundamental changes to the system and how applications interact.

My guess is (I mean: my hope is) that it has been fixed in 10.3.4.

Anyone has 10.3.4 and can check this ?

[theolein]

Originally posted by Hugin777:
As no one has posted a link (to the new exploit) yet, here goes:

Security check

NOTE: There's no automatic redirection or anything, just click the links to perform each step in turn.

PS: OpnAppFixer is just the name of the directory - I'm not fixing anything . . .

Edit: added "(to the new exploit)"

Could you tell us why anyone should click on that link? (innocuous or not) The webpage has a windows characterset encoding and you have one post....

[Hugin777]

Originally posted by theolein:
Could you tell us why anyone should click on that link? (innocuous or not) The webpage has a windows characterset encoding and you have one post....

LOL - no, actually I can't

You could do a web search for Hugin777 (there are only two: one in Iceland and me in Denmark). But that wouldn't help much either.

- But my point was: if you think you are secure, try this. If anyone tries it they will see a link to a disk image with a harmless Applescript, and a "test:" link.


Edit: link to the disk image: http://ozwix.dk/OpnAppFixer/Test.dmg - when mounted just type in "test:" in your browser.

[SMacTech]

Originally posted by Hugin777:
My guess is (I mean: my hope is) that it has been fixed in 10.3.4.

Anyone has 10.3.4 and can check this ?

Not as of 7H58 and I just installed 7H60 this morning after I patched my system yesterday, so I dunno about it.

[SMacTech]

Originally posted by Hugin777:


Edit: link to the disk image: http://ozwix.dk/OpnAppFixer/Test.dmg - when mounted just type in "test:" in your browser.

That will just open test.com. The script is safe, but it did nothing on my system.
Sorry, I missed the : at the end, duh ! The script ran.

[Hugin777]

Originally posted by SMacTech:
That will just open test.com. The script is safe, but it did nothing on my system.

Did you remember the : after test ? As in:
test:

Which browser do you use ?

[sniffer]

Originally posted by utidjian:

Thoughts?

Yes, this problem can't be easy to get around. I kind of wish it was possible to put www interaction back into the sandbox of only rendering html code or something wishful in that direction, but that's impossible within modern expectations of web interactions. A solution could be to integrate a solution similar to Paranoid Android into the firewall package, but pop-ups aren't the Mac way of doing things. Especially this isn't suitable for non-techies. I would imagine we would see some restrictions one way or another for the interaction of protocol helpers. Perhaps it means you'll need admin password to change the settings (globally and individually for the users), absolute paths for the applications, a GUI in System Preferences..? Who knows.. Anyway the "help:"<->Help Viewer ability to run scripts from the browser address field should be the first concern here I think.

[SMacTech]

My bad, I did miss the : My eyes are as bad as this vulnerability.

[Spades]

Originally posted by sniffer:
I kind of wish it was possible to put www interaction back into the sandbox of only rendering html code or something wishful in that direction, but that's impossible within modern expectations of web interactions.

I think there are two classes of defects we're seeing here. One is remote execution of applications and potentially unsafe code from a URI. The help and telnet bugs are in this class. The other class is the automatic registration of helper applications. That's the evil/malware/owned protocol stuff.

I think the browser should be put back in the sandbox, no matter what might be lost. I actually can't think of anything that would be lost though, besides a few neat tricks with help. The help and telnet bugs are technically non-standard behavior. URIs are meant to locate resources (URLs) and name resources (URNs). They are not meant to send arbitrary data to the client. If this standard was followed, there would be no help:runscript command, and the telnet protocol would only accept a server, and not parameters too. (Although it might be reasonable to put parameters in the query section of a URI, but who would intentionally do that?)

The second class just needs to be fixed. Protocol helper registration is too powerful to be done any way but interactively. I think if it was registered when the helper was launched, that would be fine.

[biscuit]

Originally posted by sniffer:
Yes, this problem can't be easy to get around...

Well, I'm no expert, but surely only three things need to be done:[list=1][*]Remove the ability of help: to run scripts via Help Viewer.[*]Stop LaunchServices from caching URL scheme info upon opening of folders/mounting of shares.[*]Turn off opening of things like .zip, .sit and .dmg by default in Safari.[/list=1]
Maybe something needs to be done about disk: too, I'm not sure on that. Even the default opening could be restored if LaunchServices no longer cached URL scheme info. Oh, one last thing would be to include the functionality of More Internet (or even RCDefaultApp) in the System Preferences.

Am I missing something?

biscuit

[Hugin777]

Originally posted by Spades:
I think there are two classes of defects we're seeing here. One is remote execution of applications and potentially unsafe code from a URI. The help and telnet bugs are in this class. The other class is the automatic registration of helper applications. That's the evil/malware/owned protocol stuff.

I think my preferred fix would be:

1) do not allow help:runscript= to run anything from /Volumes

2) do not allow the awful OpnApp scripts to open anything from /Volumes (which was my original fix for this isolated flaw)

3) disable the automatic registration of Protocol Helper Applications (who needs this ?)

4) remove shemas like "tn3270:" from the default installation OR somehow warn/disable registering new App Codes from freshly mounted volumes.

This would probably require all applications to reside on the boot volume, but as most are in /Applications already, I think it would be acceptable to most users.

[Hugin777]

Originally posted by biscuit:
Am I missing something?

To follow your line of thought, I think you are missing:

4. Stop harvesting Application Codes upon opening of folders/mounting of shares. (to fix "tn3270:")

- But if you have 3. (and disable "disk:") then 1. and 2. (and 4.) wouldn't be necessary, I guess.

I would prefer auto-open to still work, though...