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


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.
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 | # ]