Explanation, fixes for "Safari Automatically Executes Shell Scripts" vulnerability; similar to Widget vulnerability
Originally posted February 21st
As we noted below in "Odds and Ends", the "Safari Automatically Executes Shell Scripts" vulnerability that has recently garnered increased discussion is extremely similar in nature to a bug we discussed in the middle of last year, where Safari would automatically open a compressed .zip file and execute a potentially malicious Widget.
The scenario for that vulnerability went like this:
You click on a seemingly innocuous link, and view the resulting page's content. Meanwhile, a meta tag embedded in the page (META HTTP-EQUIV="Refresh") downloads a Widget in the background, and Safari -- which is, by default, set to automatically open "trusted" files, including Widgets -- quietly places the newly downloaded Widget in the ~/Library/Widgets folder. The next time you access Dashboard, the Widget is loaded in the Dashboard storage bar, and executed when you click it or drag it out of the bar. The only indication you will receive in Safari indicating that this process is happening is a generally unnoticeable refresh of the URL address bar.
The vulnerability was fixed in Mac OS X 10.4.1.
The new issue is virtually identical to the Widget vulnerability, except this time shell scripts without a "shebang" line -- which tells the script which shell to execute in -- are implicated. Without the aforementioned line, Safari no longer recognizes the content as potentially dangerous and executes shell commands without a confirmation prompt.
As we noted previously and in our coverage of the Widget vulnerability, there are some effective ways to mitigate this threat:
Turn off "Open 'safe... Turn off the option "Open 'safe' files after downloading" in the "General" pane of Safari's preferences.
Use a different browser Use an alternative browser like Firefox
Make Terminal ask for permission This is the most involved workaround, and probably the most effective. It involves replacing the Terminal application with an automator script that will intercept calls to Terminal and seek your permission to run Terminal before executing.
- First you will need to download the Automator script, created by a MacFixIt reader, by going to the "Go" menu in the Finder, navigating to the "iDisk" sub-menu, selecting "Other User's Folder" then typing "pehowland" (without quotes) and pressing return.
- Next, download the file named "Terminal.app.zip" and unstuff it. The resulting file will be an Automator script application named "Terminal.app" or just "Terminal" if you have file extension display turned off.
- Next, using the Finder, go to /Applications/Utilities and rename Terminal.app to _Terminal.app.
- Copy the replacement Terminal.app (the Automator script) into /Applications/Utilities
- Now every time a shell script attempts to launch the Terminal, the automator script will launch instead and demand user permission before the actual Terminal is launched.
If you want to undo this process, just delete my new Terminal.app and rename _Terminal.app back to Terminal.app.
The author of the script writes:
"This fix works on my machine and seems completely harmless. However, use it at you own risk - I am not responsible for any unintended side effects.
"The paranoid amongst you should also verify my script inside Automator before installing - after all, I could just be playing a nasty social engineering joke on you."
Feedback? Late-breakers@macfixit.com.
Resources
its name.
---
iMac G5, 17", 1.8 GHz, 1GB RAM
PowerBook G4, 12", 1.5 GHz, 768 MB RAM
Both OS 10.4.5
I found the name of the application that I think would do this, "RC Default." But,
I am not sure how to set it to accomplish this.
http://www.versiontracker.com/dyn/moreinfo/macosx/22977
---
iMac G5, 17", 1.8 GHz, 1GB RAM
PowerBook G4, 12", 1.5 GHz, 768 MB RAM
Both OS 10.4.5
I have since found out from author of RC Default that it is NOT a solution to this issue.
---
iMac G5, 17", 1.8 GHz, 1GB RAM
PowerBook G4, 12", 1.5 GHz, 768 MB RAM
Both OS 10.4.5
in Finder you want to choose: Go --> iDisk --> Other Users Public Folder to
access the Terminal.app Automator Script.
The substitute Terminal.app fix works fine for now. But as soon as the exploit
writers are aware of it, it will be pretty easy to circumvent.
On my Mac, I've modified the Automator workflow to use a different name for
the "real" Terminal program, and renamed the app appropriately. It can still be
circumvented, but not quite so easily now.
The Widgets were only installed, not run automatically.
this is made publicly available, surely any malware writer need simply adapt the
code to search for this as an alternative, and the fix is rendered useless?
You are correct
lets hope Apple fix it properly in the next security update or system update
You're right that it doesn't make sense to have others to tell you what to name
your Terminal application. However, that's not the only name you can name it.
You can name it whatever you please and it will still work.
That way, the "bad people in this world" can't just send out a generic script
allowing attacks on _Terminal.app because they have no idea what your
Terminal has been renamed to.
-Ryan
And surely anyone that is going to use this proceedure will be (should be) smart enough to change the lead character to something else, even to go so far as to also change the name of the real Terminal app. Then unless the malware goombas are smart or patient enough to write their code to look for any and all possible combinations (how many lines of code would that take?) you'd be safe.
1. Do your browsing in a non-admin account (as has been suggested elsewhere). (Create an admin account just for system maintenance work and set your current account to non-admin.)
2. In the System Preferences Accounts pane set up parental controls for the non-admin account to deny usage of Terminal and maybe a few other utilities. (The system won?t let you do this on an admin account.)
- by bperry1 February 22, 2006 5:46 PM PST
- If you do rename the terminal app, (or move it to a new location) be sure to CHANGE THE NAME BACK to Terminal.app and/or move it back to User/applications/utilities before running any System Updates or the updater may not update your Terminal, yes?
- Like this Reply to this comment
-
(12 Comments)