Mac OS X | Security / Privacy | Other Security / Privacy | Don't go there GURLfriend!

Don't go there GURLfriend! - 1.1

Fixes the help:// exploit

Download Now

(File Size: 153k)

Free Product Alerts!

All Time:	(4.2)
This Version:	Not rated (0.0)
Current Version:	1.1
Release Date:	2004-05-19
License:	Freeware
Downloads (this version):	3,364
Downloads (all versions):	3,364

Information Related to Version:

Broken Link? Newer Version? Tell us!

Product Description:

Don't go there GURLfriend! fixes the help:// exploit in Safari which can allow for remote code execution.

What's new in this version:

Patches more occurances of the exploit, making it virtually impossible to use the OpenApp help:// expoit.
Now, as an extra security measure, patching will also disable Safari's automatic opening of "Safe" files. The user can turn this potentially dangerous feature back on in the Safari Preferences.

Operating System Requirements:

This product is designed to run on the following operating systems:

Mac OS X 10.3
Mac OS X 10.2
Mac OS X 10.1
Mac OS X 10.0

Additional Requirements:

Mac OS X

Feedback Summary:

This Version:
Overall Rating:	Not rated (0.0)	Features:	Not rated (0.0)	Support:	Not rated (0.0)
Ease of Use:	Not rated (0.0)	Quality / Stability:	Not rated (0.0)	Price:	Not rated (0.0)

Key to Types of Feedback:

Reviews Reviews Troubleshooting Usage Tips Developer Notes Commentary Featured Reviews

This is the first truly critical security flaw in OS X - Version: 1.1, 5/19/2004 10:58PM PST

MacHFC DEV

Whatever. There have been local/remote attacks allowing users to gain root access to OS X. That is far more dangerous than an applescript exploit. Apple fixed it quick enough. Get a clue, man.

Another alternative - Version: 1.1, 5/19/2004 05:02PM PST

(1 of 2 users found this comment useful)

morgancain

As posted by jhurshman on Macfixit, you can do this to edit your Info.plist inside the Help appilcation from Terminal:

sudo cp /System/Library/CoreServices/Help\ Viewer.app/Contents/Info.plist /System/Library/CoreServices/Help\ Viewer.app/Contents/Info.plist.original; checkLine=`grep -n 'NSAppleScriptEnabled' /System/Library/CoreServices/Help\ Viewer.app/Contents/Info.plist.original | awk -F : '{print $1}'`; theLine=`echo "$checkLine + 1" | bc`; sed -e "$theLine s/true/false/g" /System/Library/CoreServices/Help\ Viewer.app/Contents/Info.plist.original > ~/Info.plist.nu; sudo cp ~/Info.plist.nu /System/Library/CoreServices/Help\ Viewer.app/Contents/Info.plist

OR if you're paranoid and want to do it manually, you can walk through this recipe (again from Terminal):

sudo -s [enter password]
vi /System/Library/CoreServices/Help\ Viewer.app/Contents/Info.plist
type '/NSApple' to search for NSApplescriptEnabled
down-arrow to next line after NSApplescript, use 'x' key to delete the word 'true'
type 'i' key for insert mode, type 'false', hit 'esc' key
type 'ZZ' to quit and save
exit; exit

Your results should look something like this in the area you edited: 

<key>NSApplescriptEnabled</key>
<false/>

And basically, what you are doing is editing the NSApplescriptEnabled key in the Info.plist file inside the Help View application to be false instead of true.

Works for me!

PS: Trying to post special characters in comment here at VT is like hammering nails with your forehead!

Does it change 'em all? - Version: 1.0, 5/19/2004 07:50AM PST

(1 of 1 users found this comment useful)

JimT3

I haven't bothered to use this program. Instead I used More Internet to change my help:// URI handler. Not a perfect solution, but a better one.

What I'm curious about is whether or not it changes all OpenApp.scpt files on the machine. The issue doesn't exist simply with the OpenApp.scpt file within the Help Viewer app - it can be exploited for any OpenApp.scpt file that exists anywhere else.

Personally, I have 245 of them on my machine. And I have tested them - they can be exploited. So if this thing only changes the Help Viewer OpenApp.scpt one, there are still 244 open security holes. If it changes all of them, then good, it's covering it better.

Of course, the program would need to be re-run every time a new application is installed to ensure that any OpenApp.scpt files in there are changed as well.

Most Recent Replies: View All 1 Replies

Does it change 'em all?