help: protocol Security Hole

From xcl8

Patcher for Safari/Help Viewer Vulnerability? - I've not tested this personally, but MU today lists Don't go there GURLfriend! 1.0 which claims to fix the help:// exploit in Safari mentioned yesterday.

"(from http://isophonic.net/ source site)

Don't Go There, GURLfriend 1.0
18 May 2004
We've just released Don't Go There, GURLfriend! 1.0 . DGTGF is an application you can use to patch away the OS X exploit found at http://bronosky.com/pub/AppleScript.htm quickly and efortlessly."


Many (understandably) are leery of running this sort of thing however.
A MU reader posted another suggestion (similar to what was suggested yesterday as a better option that just disabling opening 'safe' files) - remapping the Help association using More Internet prefs pane to use a text editor instead.
Another reader wrote with his suggested fix:

" Hi Mike, here's a quick, and harmless (read; reversible) fix for the help autolaunch vulnerability:

First, make a Backup copy of /Library/Documentation/Help/MacHelp.help.

Next do a show contents on the original, and
find:Contents/Resources/English.lproj/shrd/OpnApp.scpt
Make the change as shown below (adding the two dashes in front of "open file completeParam of the startup disk" (This comments out that line of code, so it won't run.)

on <event helphdhp> (completeParam)
-- localizable text
set cancelBtn to "Cancel"
set errorText to "The item cannot be
opened. It may be disabled or not installed."
--end localizable text

try
tell application "Finder"
-- open file completeParam of the startup disk
end tell

on error errMsg number errNum
display dialog errorText buttons
{cancelBtn} default button 1 with icon 0
return
end try
end <event helphdhp>


Save the file.
Remove all your foreign language versions of the same help file (at the Resources level)

After doing this, the help file will still run, but will not be able to "open xyz for me"
Later on, you can replace your patched copy with the backup copy of MacHelp.help you made in step one, and apply Apple's (forthcoming) fix to it.
Meanwhile, you'll be safe from that exploit.
hth
Cordially, Tracy V. "
 
This isn't a hole in Safari, just how OS X handles the help:// protocol. Safari, IE, Mozilla(I think) all hand off those protocols to the OS, and the bug is in the Applescript and not any browser.
 
Disabling the opening of 'safe' attachments will prevent an attacker from first planting a script on your computer, then executing it with the help:// protocol. It doesn't stop the attacker executing a script they already know is there.
 
Apparently you can use an Applescript in the Help program to execute pretty much any unix command, not just something on a dmg that you have to download and mount.
 
Unsanity today released Paranoid Android, which the company says can protect you from a serious security flaw under Mac OS X. "A vulnerability in Apple's Mac OS X results in a potential situation in which a malicious person could execute arbitrary commands on your machine, such as deleting your home directory, or doing other harmful actions," notes Unsanity. "This vulnerability involves the use of URL "schemes". These are the part of a web address that specifies what program should be used to handle the address." Paranoid Android works by watching the URL schemes that are requested and delaying them until the user has had a chance to say whether or not they would like to proceed. "Paranoid Android is completely free - we do this for the benefit of Mac community," notes the Unsanity Web site. *

Get it here.
 
Well i have just been informed and verified a massive safari exploit that would let you execute almost any command on someones computer. All they have to do is go to a URL containing the script and be using safari.

Here is a harmless site that has the script on it and will demonstrate the script using a harmless du command.

http://bronosky.com/pub/AppleScript.htm
 
From MacFixIt;

An easier -- and more thorough -- solution is to simply disable/redirect the help protocol so that it is no longer handled by Help Viewer. (The side effect of this approach is that if an application uses the help URL protocol to communicate with Help Viewer, it will no longer be able to do so. However, Help Viewer will still function normally, so the inconvience should be fairly minor until Apple provides a more comprehensive fix.)

To use this method, follow these steps:


Download and install the More Internet preference pane.

http://www.versiontracker.com/dyn/moreinfo...fo/macosx/16066

Open System Preferences and switch to the new More Internet pane.
In the list of protocols on the left, select help.
Either click Remove to remove the help protocol association altogether, or (recommended) click the Change button to chose an alternate application. We suggest something obviously not applicable; a popular choice is the Chess application.


After making this change, help URLs will cause your chosen application to open instead of Help Viewer; since you've hopefully chosen an application that doesn't know what to do with help URLs, nothing will happen. (Don't choose Safari to handle help URLs, since Safari will pass those URLs off to Help Viewer.) Choosing the Chess application is recommended because it's not likely to be launched automatically by the OS or other applications, so if it does launch on its own after making this change, you'll know the reason is that a URL using the help protocol was "opened."
 
I came across this a while ago, I simply renamed OpnApp.scpt and that stop the problem for me.

Also as the exploit is limited to terminal commands without arguments, it makes it a little difficult to do anything major.

between that and the fact that you would know the site that did this which is fairly incriminating for anyone trying to do something malicious with this, I don't think this has a very high risk of being used...

Sad that it is any risk at all though. :confused:
 
But couldn't someone send out an email with a malicious link just as these windows goofballs do all the time time with executables?
 
Back
Top