Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > macOS > Serious Security Flaw in Mac OS X/Safari/Help Viewer

Serious Security Flaw in Mac OS X/Safari/Help Viewer (Page 7)
Thread Tools
smeger
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status: Offline
Reply With Quote
May 20, 2004, 05:58 PM
 
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.
Geekspiff - generating spiffdiddlee software since before you began paying attention.
     
smeger
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status: Offline
Reply With Quote
May 20, 2004, 05:59 PM
 
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.
Geekspiff - generating spiffdiddlee software since before you began paying attention.
     
sniffer
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 20, 2004, 06:04 PM
 
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.
( Last edited by sniffer; May 20, 2004 at 06:11 PM. )

Sniffer gone old-school sig
     
smeger
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status: Offline
Reply With Quote
May 20, 2004, 06:52 PM
 
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.
Geekspiff - generating spiffdiddlee software since before you began paying attention.
     
sniffer
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 20, 2004, 08:10 PM
 
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.]
( Last edited by sniffer; May 20, 2004 at 11:06 PM. )

Sniffer gone old-school sig
     
alcatholic
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 21, 2004, 12:30 AM
 
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
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 08:58 AM
 
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)"
( Last edited by Hugin777; May 21, 2004 at 09:25 AM. )
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
May 21, 2004, 09:25 AM
 
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?
-DU-...etc...
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 09:47 AM
 
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
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 21, 2004, 10:07 AM
 
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....
weird wabbit
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 10:16 AM
 
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.
( Last edited by Hugin777; May 21, 2004 at 10:21 AM. )
     
SMacTech
Mac Elite
Join Date: Nov 2001
Location: Trafalmadore
Status: Offline
Reply With Quote
May 21, 2004, 10:22 AM
 
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
Mac Elite
Join Date: Nov 2001
Location: Trafalmadore
Status: Offline
Reply With Quote
May 21, 2004, 10:26 AM
 
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
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 10:28 AM
 
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
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 21, 2004, 10:30 AM
 
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.

Sniffer gone old-school sig
     
SMacTech
Mac Elite
Join Date: Nov 2001
Location: Trafalmadore
Status: Offline
Reply With Quote
May 21, 2004, 10:31 AM
 
My bad, I did miss the : My eyes are as bad as this vulnerability.
     
Spades
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 21, 2004, 11:05 AM
 
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
Mac Enthusiast
Join Date: Jul 2002
Location: London, UK
Status: Offline
Reply With Quote
May 21, 2004, 11:11 AM
 
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
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 11:20 AM
 
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
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 11:37 AM
 
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...
     
sniffer
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 21, 2004, 11:46 AM
 
Originally posted by biscuit:
[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]
1. Agree, that's obvious. At least isolate Help Viewer from interactivity from other apps. (All it's supposed to is to show help files and open apps. How hard is that?) Also there is concerns with the telnet: thing.
2. That one might have several approaches. I.e. isolate to only apps in the Application folder. Direct paths. Require admin password for changing the setup of protocol helpers. Etc. Not sure which one would be the best approach thought. But I agree with your suggestion should be part of the solution.
3. I don't think that would be necessary, or very practically. Opening of "secure" files isn't a direct part of the security flaw here.
( Last edited by sniffer; May 21, 2004 at 11:55 AM. )

Sniffer gone old-school sig
     
n8910
Junior Member
Join Date: Sep 2000
Location: Milwaukee, WI
Status: Offline
Reply With Quote
May 21, 2004, 02:32 PM
 
One more thing:

afp://;AUTH=No%20User%20Authent@server/share/


and any other protocols that can mount on the desktop, smb, ftp, etc..


: (
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 03:51 PM
 
Originally posted by n8910:
[..]_and any other protocols that can mount on the desktop, smb, ftp, etc..
You are right, of course.

I have updated my (new) exploit example page with the "ftp:" protocol. Several others are possible, as you mention.

Edit: I have now sent my second email to [email protected] with your newest findings. Actually I don't think it is a good idea to flood them with email; but a summary of current public knowledge once in a while may be a good thing
( Last edited by Hugin777; May 21, 2004 at 04:24 PM. )
     
sjk
Forum Regular
Join Date: Feb 2002
Location: Hawaii
Status: Offline
Reply With Quote
May 21, 2004, 04:42 PM
 
Originally posted by utidjian:
If Apple has known about this for very near 3 months it is too horrible to think that they overlooked or dismissed it.
Yet sometimes people react as if Apple is in some kind of vacuum about security issues discussed around the 'net. If I believed they could be that out-of-touch I wouldn't be using their products.
Still...
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.
Yes indeed, a public acknowledgment would appear to be in everyone's better interest, especially when a problem this significant is generating vast amounts of both useful and misleading information. It may ultimately be more harmful for them (and other companies) to remain silent about issues "everyone" else already knows about rather than openly admitting them. That sort of "communication secrecy" should (usually) be relegated to a pre-Internet type of behavior, IMO. Of course I won't pretend to know their reasons since I don't have that information.

I enjoyed the speculative perspectives in your post, btw, and appreciate all the time and energy folks have devoted to better understand and deal with this problem (a word I prefer not to overuse) in light of Apple's absence. I came into this thread late and the recent summaries have been particularly helpful... thanks!
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 05:08 PM
 
Originally posted by sjk:
I came into this thread late and the recent summaries have been particularly helpful... thanks!
This is the "summary of current public knowledge" i just sent to Apple:
  • OpnApp.scpt - this is just awful; it gladly runs everything everywhere
  • help:runscript= - this could just be removed from the browser as it doesn't even break HelpViewer
  • automatic registration of URLHandlers when a volume is mounted - who needs this ? One doesn't even have to open the application !
  • several default URLHandlers for non-installed applications. So an offender could probably mount a volume with an application which application code is "GFTM" and open "tn3270:".

Note that several URI schemas (protocols) can be used to mount a volume, including:
disk: http: ftp: webdav: smb: afp:

- Did I miss anything ?
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 21, 2004, 06:08 PM
 
Originally posted by Hugin777:
This is the "summary of current public knowledge" i just sent to Apple:
  • OpnApp.scpt - this is just awful; it gladly runs everything everywhere
  • help:runscript= - this could just be removed from the browser as it doesn't even break HelpViewer
  • automatic registration of URLHandlers when a volume is mounted - who needs this ? One doesn't even have to open the application !
  • several default URLHandlers for non-installed applications. So an offender could probably mount a volume with an application which application code is "GFTM" and open "tn3270:".

Note that several URI schemas (protocols) can be used to mount a volume, including:
disk: http: ftp: webdav: smb: afp:

- Did I miss anything ?
I just tested out your test ap along with ftp: smb: and afp: . Sh�t, works with them all. I also presume that webdav also works. (http: and mailto: are about the only ones that don't work by default!).

I can only say that we OSX users have been extremely lucky that this hasn't been abused before
weird wabbit
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 21, 2004, 06:16 PM
 
Originally posted by Hugin777:
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. Stop harvesting Application Codes upon opening of folders/mounting of shares. (to fix "tn3270:")
1. I disagree. The fix for this is not to allow help:runscript to do anything at all. The ability for a URL to run a script should not be there.

2. If #1 is fixed, the OpnApp scripts can no longer do us any harm at all.

3. Agreed. Registration of protocols should only happen on application launch.

4. The trouble about harvesting creator codes/bundle ID's is that it's always been kind of fundamental to the way the Mac works. I'm really not sure how to fix this one, but I see two possible solutions:

4a. Get rid of the default settings pointing to non-existent apps (problems could still happen, especially if some shareware app sets itself up for a few protocols and then you decide you don't like it and trash it).

4b. Disallow Internet Config from launching apps on removable volumes, server, or disk images (but you'll still be vulnerable to the app being packaged in a .zip or .sit and going to your Desktop, thus sitting on a local disk).

As you can see, I can't find a good solution for the variant that I discovered. This is why this one scares me the most, and why I'm now wondering if I should have kept my mouth shut.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
sniffer
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 21, 2004, 07:11 PM
 
Originally posted by CharlesS:
As you can see, I can't find a good solution for the variant that I discovered. This is why this one scares me the most, and why I'm now wondering if I should have kept my mouth shut.
We've been running around like head chopped chickens for days now. No sire, you have nothing you should regret on. You and others contributions have stabilized the situation IMO.

The person at Apple that decided we needed a all in one; no-rule solution in the OS on how to handle trusted and untrusted documents how-ever.. That's a different story.
( Last edited by sniffer; May 21, 2004 at 07:18 PM. )

Sniffer gone old-school sig
     
smeger
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status: Offline
Reply With Quote
May 21, 2004, 07:18 PM
 
I've written a whitepaper discussing the different variants of this exploit, and why I think Paranoid Android is needed until Apple fixes things.

Note: Apple's 5/24 (what's with the date?) security update only fixes a small subset of possible exploits, so as far as I'm concerned, this bug is still wide-open. My sample exploit which is linked on the whitepaper page (the one that inspired me to write Paranoid Android) still works.
Geekspiff - generating spiffdiddlee software since before you began paying attention.
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 07:18 PM
 
Originally posted by CharlesS:
1. I disagree. The fix for this is not to allow help:runscript to do anything at all. The ability for a URL to run a script should not be there.

[..]
4a. Get rid of the default settings pointing to non-existent apps (problems could still happen, especially if some shareware app sets itself up for a few protocols and then you decide you don't like it and trash it).
[..]
Apple apparently chose your solution to (1) in their just released Security Update to HelpViewer That is, "help:runscript=../../Scripts/Info%20Scripts/Current%20Date%20&%20Time.scpt" is just ignored now (on my machine).

As to (4a) you could argue that deletion of a user installed Helper Application should remove the URI scheme also. But as it is I think it would be acceptable, although not perfect, if it was up to the user/applications to not just remove a Helper Application without unregistering the URI schema...
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 21, 2004, 07:22 PM
 
Originally posted by smeger:
Note: Apple's 5/24 (what's with the date?) security update only fixes a small subset of possible exploits, so as far as I'm concerned, this bug is still wide-open.
...thanks to my big mouth.

I'm just feeling guilty because of the e-mail I got back from Apple when I submitted the bug - "Because of the potentially sensitive nature of security vulnerabilities, we ask that this information remain between you and Apple while we investigate it further." Of course, the cat was already out of the bag at that point...
( Last edited by CharlesS; May 21, 2004 at 07:31 PM. )

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 21, 2004, 07:28 PM
 
Originally posted by Hugin777:
Apple apparently chose your solution to (1) in their just released Security Update to HelpViewer That is, "help:runscript=../../Scripts/Info%20Scripts/Current%20Date%20&%20Time.scpt" is just ignored now (on my machine).
Good to know. At least one of the vulnerabilities is patched.

As to (4a) you could argue that deletion of a user installed Helper Application should remove the URI scheme also. But as it is I think it would be acceptable, although not perfect, if it was up to the user/applications to not just remove a Helper Application without unregistering the URI schema...
Well, what if you delete one app in order to download and install a new version?

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
sniffer
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 21, 2004, 07:35 PM
 
I disabled PA and this came up in safari when typing "help:runscript=" in Safari Address field. Happens when I type "afp:" as well. I've just applied the Apple patch.

Sniffer gone old-school sig
     
smeger
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status: Offline
Reply With Quote
May 21, 2004, 07:44 PM
 
Originally posted by CharlesS:
...thanks to my big mouth.

I'm just feeling guilty because of the e-mail I got back from Apple when I submitted the bug - "Because of the potentially sensitive nature of security vulnerabilities, we ask that this information remain between you and Apple while we investigate it further." Of course, the cat was already out of the bag at that point...
I thought that I'd realized independently that you could use Info.plist to register an arbitrary URL scheme handler, but maybe you suggested it first and I didn't notice. In any case, I think this was one of those things where the time was right and 87 billion people realized it all at once.

Nothing to feel bad about.
Geekspiff - generating spiffdiddlee software since before you began paying attention.
     
smeger
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status: Offline
Reply With Quote
May 21, 2004, 07:46 PM
 
Originally posted by sniffer:
I disabled PA and this came up in safari when typing "help:runscript=" in Safari Address field. Happens when I type "afp:" as well. I've just applied the Apple patch.
sniffer, that's Paranoid Android presenting its dialog, but since you'd disabled it, it can't find the localized versions of its strings and icon. Once it's loaded into a running process (Safari), it stays loaded. You have to quit and relaunch Safari to unload Paranoid Android.
Geekspiff - generating spiffdiddlee software since before you began paying attention.
     
gregomni
Forum Regular
Join Date: Feb 2001
Location: Portland, OR, USA
Status: Offline
Reply With Quote
May 21, 2004, 07:56 PM
 
The help:runscript= bug has been fixed. Security Update is in Software Update right now...
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 21, 2004, 07:57 PM
 
Originally posted by smeger:
I thought that I'd realized independently that you could use Info.plist to register an arbitrary URL scheme handler, but maybe you suggested it first and I didn't notice. In any case, I think this was one of those things where the time was right and 87 billion people realized it all at once.

Nothing to feel bad about.
I figured that the thing started with my little flamewar with kampl when I brought LaunchServices into the mix:

http://forums.macnn.com/showthread.p...=4#post1994990

with the sudden "Oh Crap" realization I added with an edit. That led to Developer doubting whether LaunchServices would cache the creator code on browsing, my proposal of the tn3270: exploit, and finally your realization that the problem was even worse than I thought it was by pointing out that it would work with any fake protocol.

If you came up with the protocol idea independently, and just didn't post until we were discussing LaunchServices, than that makes it okay and I don't have to feel guilty anymore, I guess. I'm still somewhat upset at this whole thing, though...
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 07:59 PM
 
Originally posted by smeger:
Note: Apple's 5/24 (what's with the date?) security update only fixes a small subset of possible exploits, so as far as I'm concerned, this bug is still wide-open.
What exactly has been fixed ?

help:runscript= is apparently now ignored when originating from browsers.

A line like:
2004-05-22 00:56:49.456 Help Viewer[17890] help://runscript called by another application!
is added to the console.log.

More ?
( Last edited by Hugin777; May 21, 2004 at 08:21 PM. )
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 21, 2004, 08:02 PM
 
I'm going to take this time to reiterate an important fact:

The Help Viewer exploit made it to Slashdot, causing tremendous publicity and forcing Apple to fix it.

AFAIK, the various protocol attacks, though known, have not been as widely publicized as the help: exploit. Therefore, it is urgent that you all write to Apple describing the exploits discovered in this thread:

[email protected]

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
sniffer
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 21, 2004, 08:09 PM
 
Originally posted by smeger:
sniffer, that's Paranoid Android presenting its dialog, but since you'd disabled it, it can't find the localized versions of its strings and icon. Once it's loaded into a running process (Safari), it stays loaded. You have to quit and relaunch Safari to unload Paranoid Android.
Damn, you right.

[edit: removed unnecessary information.]
( Last edited by sniffer; May 21, 2004 at 08:20 PM. )

Sniffer gone old-school sig
     
smeger
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status: Offline
Reply With Quote
May 21, 2004, 08:13 PM
 
Originally posted by CharlesS:
I figured that the thing started with my little flamewar with kampl when I brought LaunchServices into the mix:

http://forums.macnn.com/showthread.p...=4#post1994990
Gotcha. Yes, I think that did suggest it to me. But I also think I would have thought of it pretty quickly regardless. And I think it's much better that we "whitehats" think of this stuff than waiting for the "blackhats" to do it.
Geekspiff - generating spiffdiddlee software since before you began paying attention.
     
Developer  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 21, 2004, 08:21 PM
 
Originally posted by Hugin777:
What exactly has been fixed ?
  • help:runscript= is apparently now ignored when originating from browsers
  • telnet: also now apparently ignores parameters (like -nFilename)
More ?
The Security Update for Panther does not update the Terminal which can still overwrite files. I'm uncomfortable with this.
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
smeger
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status: Offline
Reply With Quote
May 21, 2004, 08:33 PM
 
Originally posted by Developer:
The Security Update for Panther does not update the Terminal which can still overwrite files. I'm uncomfortable with this.
My test exploit (page contains a link, not the exploit itself) still works. I'm uncomfortable with this as well.
Geekspiff - generating spiffdiddlee software since before you began paying attention.
     
n8910
Junior Member
Join Date: Sep 2000
Location: Milwaukee, WI
Status: Offline
Reply With Quote
May 21, 2004, 08:39 PM
 
We also got nifty logging!

2004-05-21 19:33:09.607 Help Viewer[361] help://runscript called by another application!

This security update unfortunately still leaves many exploits open.


By next Friday perhaps?
( Last edited by n8910; May 21, 2004 at 08:49 PM. )
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 08:41 PM
 
Originally posted by Developer:
The Security Update for Panther does not update the Terminal which can still overwrite files. I'm uncomfortable with this.
Right. I edited my post above

It appears that the person that told me about the telnet: fix is running 10.3.4 And when I tested I forgot the // after telnet: . . .

So with 10.3.4 both telnet: and help:runscript should be fixed. But not automatic URLHandler registration, I guess...
     
lixlpixel
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 21, 2004, 08:48 PM
 
whats the story with securityfocus.com ?
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 21, 2004, 08:57 PM
 
Originally posted by lixlpixel:
whats the story with securityfocus.com ?
The telnet: vulnerability has been known for a while, but the only thing it can do (AFAIK) is to "empty" files: telnet://-nFilename will create an empty file named Filename in your home directory, "emptying" it if it exists. (was this what you asked? )

AFAIK it has been fixed in 10.3.4.

- The list of vulnerable browsers at securityfocus.com sure is impressive ! (Edit: but Safari 1.2 isn't on the list !?)
( Last edited by Hugin777; May 21, 2004 at 09:03 PM. )
     
lixlpixel
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 21, 2004, 09:06 PM
 
- The list of vulnerable browsers at securityfocus.com sure is impressive !
yes - that's what i meant - sorry - the menu of their site was not obvious enough for me.
i saw that it was about the telnet: thing AFTER i posted this ...
     
alphasubzero949
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
May 21, 2004, 09:53 PM
 
Okay, I've applied the SU patch and installed PA.

Is it "safe" to redirect help: back to Help Viewer for the time being?
     
sniffer
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 21, 2004, 10:43 PM
 
Originally posted by alphasubzero949:
Okay, I've applied the SU patch and installed PA.

Is it "safe" to redirect help: back to Help Viewer for the time being?
The software update patch fixed Help Viewer, so yes you can redirect help: back to Help Viewer now. (I've tested it to work ok on my 10.3.3 installation.)

Sniffer gone old-school sig
     
 
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 05:51 PM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,