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

Avoid a security vulnerability in Safari Web Browsers
As most of you know, macosxhints is not a 'breaking news' site. We generally post things that aren't time sensitive, and try to stay away from news as much as possible -- there are many better sources for Mac-related news out there than this one!

As such, I didn't post anything here about either the Leap.A worm/trojan or the Bluetooth worm, as they were both thoroughly covered on other sites, and there wasn't much 'tip like' that could be considered tip-worthy about either of them, beyond 'use common sense when downloading and opening files from others.'

Yesterday's news of a Safari vulnerability, however, is different. While the Leap.A and Bluetooth programs required active user participation (you had to agree to accept a file, then expand and run it, for instance), this latest Safari vulnerability is riskier. You can actually execute a program on your Mac by just clicking a link on a website, or, on a truly malicious page (using some HTML programming tricks) by simply visiting that page .

Other sites have done a very good job of explaining how this particular vulnerability works in detail, so I'll just summarize it here. In a nutshell, a shell script can be written and then zipped in such a way that it will automatically expand and then execute on a user's machine. This shell script, could, of course do anything your user could do -- including, as an example, installing the Leap.A worm.

Thankfully, the short-term workaround is fast and simple: If you use Safari, open its Preferences, and in the General tab, uncheck the 'Open "safe" files after downloading' checkbox, as seen here:


From now on, you'll have to expand downloaded files yourself, but that's a small price to pay for insuring your machine won't automatically fall victim to this vulnerability. Note that you still need to practice common sense with downloaded files -- if you expand the archive and then run the resulting file, it will still do whatever damage it would have automatically done. You won't, however, need to worry about this happening without your intervention.

It's quite ironic that Apple themselves put the word safe in quotes there, as it's clear to me that almost no file from the internet should be assumed safe. Note that Safari ships with this option enabled by default, so many users may not even know they've agreed to have archives expand automatically on their machines. Given that our recent poll showed that Safari has close to a 60% browser share, this is indeed scary. So please, if you use Safari, take a second to disable the automatic expansion of downloaded files.

Edit: I edited the explanation of how one could be infected, to hopefully make it clearer...
    •    
  • Currently 2.00 / 5
  You rated: 2 / 5 (4 votes cast)
 
[20,835 views]  

Avoid a security vulnerability in Safari | 39 comments | Create New Account
Click here to return to the 'Avoid a security vulnerability in Safari' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
This security vulnerability is more "generic"
Authored by: jmacak on Feb 22, '06 08:09:46AM
This is not so much a vulnerability of Safari as it is of Mac OS X. (The Safari option might be said to enhance the vulnerability.) Users must be encouraged to be wary of any downloaded file, no matter the method of download.

See this article for further info:

http://www.unsanity.org/archives/000449.php

Jim Macak
Macintosh help and consulting
Milwaukee, WI
http://www.yourmacdoc.com/

[ Reply to This | # ]
the main problem is silent execution
Authored by: hayne on Feb 22, '06 08:35:21AM
While I can agree that there is an underlying generic problem, the really serious problem is (as Rob has explained in the article) that Safari will execute the script without any user interaction.

The fact that a downloaded file can masquerade as something it is not (like the Leap-A trojan or the "generic" problem described by that Insanity article) is not nearly as serious a problem since for that requires that the user double-click on the file after downloading.

[ Reply to This | # ]

Avoid an 'automatic' security exploit in Safari
Authored by: kL on Feb 22, '06 08:13:49AM

Rename/move Terminal.app somewhere else to protect against that and similar attacks (disabling opening in Safari won't protect you against archives you open yourself).



[ Reply to This | # ]
Avoid an 'automatic' security exploit in Safari
Authored by: dayhox on Feb 22, '06 10:07:27AM

The Terminal app can be worked around. All I had to do was write an AppleScript

do shell script "defaults write com.apple.Safari AutoOpenSafeDownloads 0"

d



[ Reply to This | # ]
Avoid an 'automatic' security exploit in Safari
Authored by: kL on Feb 23, '06 12:49:55PM

NO! Read my post again - I've said this bug is not limited to Safari.

Safari is only one OF MANY WAYS you could get harfmul archive. Your script just disables automatic opening in Safari, but expliot STILL WORKS if you open archive manually in Safari, or in Mail, iChat or from any other source.



[ Reply to This | # ]
The Culprit
Authored by: googoo on Feb 22, '06 09:21:12AM
I think the real vulnerability is in BOMArchiveHelper.app. Read my detailed explanation in today's MacIntouch (2006-02-22).

-Mark



[ Reply to This | # ]
The Culprit
Authored by: hamarkus on Feb 22, '06 10:08:26AM

I agree with you, BOMArchiveHelper.app automatically opening files is the problem (there might be some useful cases but BOM should never be allowed to open a file which wants to be opened by Terminal.app).

If you have Stuffit installed you can also use RCD (both via extension and MIME type) to open .zip and any other compressed formats with it, with that you can still uncompress them in the Finder.
However, the next 'virus' might simply override this setting (as the sample Secunia.mov file does) and ask the OS to be openend by BOM, although Safari and Mail might prevent this.

I still do not understand by which mechanism the 'Open with' app in the 'Get Info' window is set. It is not the filename extension nor the Creator/Type nor the MIME type.



[ Reply to This | # ]
The Culprit
Authored by: bomolub on Feb 22, '06 01:58:29PM

It's done with a resource of type 'usro' in the resource fork.

http://mjtsai.com/blog/2004/01/27/bruce_horn_interview



[ Reply to This | # ]
The Culprit
Authored by: hamarkus on Feb 22, '06 05:09:26PM

Thanks for the info. So Apple 'simply' has to stop considering files which have ‘icns' and ‘usro' resources pointing to Terminal.app as 'safe' files.

Interestingly, the resource fork of secunia.mov contained the complete path to Terminal.app. Do the ‘icns' and ‘usro' resources always contain the complete path?



[ Reply to This | # ]
& Mail.app !?
Authored by: mayaahh on Feb 22, '06 10:26:46AM

I think there is a risk with mail too : if you receive a mail with a movie icon and that file's name is somethings.mov and the fake is credible (imagine a mac-related mailling-list sending a video about security on Mac !), you can't know it's a shell script unless you download it, then hit command+I, insted of just double-clic on it

I think the solution have to be a bash one : I'm looking for a bash enough competent guy to crak it in order to add a confirmation step before executing file script : Prompt should say "do you really want to execute the file filename.mov ?" No ! The only restriction is that crontab should not be affected



[ Reply to This | # ]
Resource Forks!!
Authored by: googoo on Feb 22, '06 01:58:23PM

It seems to me that there are several problems that all go back to one central issue: resource forks! Mac OS X uses the file extension to determine which app to use if a file does not have a resource fork. If a file has a resource fork, the application associated with the file can be different from the application associated with the extension. You set this in the Finder Get Info menu by changing the Open with option. Usually this is not an issue because files that arrive by download, E-mail, or other means come without resource forks. There are some exceptions, though. Resource forks can be included in ZIP archives, and BOMArchiveHelper.app reconstructs them for the extracted files. Mail.app can handle resource forks as well. I am sure there are others, too. This is a huge problem.

A compounding factor is that Terminal.app will run shell commands in a UNIX executable file. All you have to do is set Terminal.app as the application and double-click the file. Then Terminal.app opens a new shell, and executes the commands in the file.

Combine these two issues, and you get a mess. You can give a file a harmless sounding (and incorrect) extension and set its default application to Terminal.app. The result: double-clicking a seemingly harmless photo or movie opens Terminal.app and runs a shell script that deletes all your files (no administrative permission needed)! Then, Safari was set to open certain "safe" files for us. The problem is that "safe" files are determined by extension (or actually MIME type) instead of associated application.

And this is the "safe" OS!?

-Mark



[ Reply to This | # ]
Resource Forks!!
Authored by: john108 on Feb 22, '06 02:55:49PM

Exactly - anything else but changing from HFS to a proper POSIX compliant Unix file system (without resource forks) will be a short term fix till the next exploit comes along - this was only a POC - once it is realised how easy it is to exploit Macs the fun will begin. It's time to say goodbye to Classic and to take the OS that Next developed and match it to a proper secure Unix file system where this type of nonsense just wouldn't happen.



[ Reply to This | # ]
& Mail.app !?
Authored by: mibo on Feb 23, '06 04:05:11AM

Yeah, Mail.app is a much more secure hole than Safari:
http://www.heise.de/english/newsticker/news/69919
They have tested both 10.3.9 and 10.4 Mail. While Panther Mail asked what to do with the file Tiger Mail just starts the script without any asking. So mail attachments are a bigger risk to your system. Maybe somebody who uses Mail on Tiger could test the defaults write solution for Safari with Mail because Mail doesn´t seem to have a switch in it´s gui to bring up the dialog before executing scripts.



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: jump420 on Feb 22, '06 10:19:30AM

i love that feature though. such a convenience. is there another way instead of deselecting the open "Safe" files? thanks



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: mayaahh on Feb 22, '06 10:28:10AM

I think there is a risk with mail too : if you receive a mail with a movie icon and that file's name is somethings.mov and the fake is credible (imagine a mac-related mailling-list sending a video about security on Mac !), you can't know it's a shell script unless you download it, then hit command+I, insted of just double-clic on it

I think the solution have to be a bash one : I'm looking for a bash enough competent guy to crak it in order to add a confirmation step before executing file script : Prompt should say "do you really want to execute the file filename.mov ?" No ! The only restriction is that crontab should not be affected



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: pub3abn on Feb 22, '06 10:37:42AM
There is discussion of the Mail application vulnerability here: http://macdailynews.com/index.php/weblog/comments/8652/

[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: ppp on Feb 22, '06 10:28:16AM
The command line to disable this feature in Safari is:

defaults write com.apple.Safari AutoOpenSafeDownloads 0

Which can be used in Apple Remote Desktop to turn the function off for a large number of computers in a single action. Safari will need to be quit and relaunched, if it running, for the change to take effect.

[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: xyz3 on Feb 22, '06 07:03:25PM

I suggest using:

defaults write com.apple.safari AutoOpenSafeDownloads -bool false

Which results in:

<key>AutoOpenSafeDownloads</key>
<false/>



defaults write com.apple.Safari AutoOpenSafeDownloads 0

The above command changes the bool to a string- and I am not positive if Safari respects this change.

<key>AutoOpenSafeDownloads</key>
<string>0</string>



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: xyz3 on Feb 22, '06 07:11:16PM

After testing, it appears both string and bool work correctly in 10.4.5 with Safari Version 2.0.3 (417.8) - at the present time.



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: pub3abn on Feb 22, '06 10:55:25AM

Rob: In your phrase, "It's quite ironic..." I think you chose the wrong word (see, for example, http://ikebomber.net/posts/misused.html or http://sc.tri-bit.com/Irony). I think maybe you mean "It's quite telling," or "It's quite a coincidence," or something along that line.



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: mayaahh on Feb 22, '06 11:02:53AM

Is there abash enough competent guy to crak it in order to add a confirmation step before executing file script : Prompt should say "do you really want to execute the file filename.mov ?" The only restriction is that crontab should not be affected.

That would be the ultimate fix !



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: genericuser on Feb 22, '06 11:10:00AM

That's not ironic, that's realistic because it shows that they understood that no file can automatically be labeled safe.

It would be ironic if they did not use the scare quotes.



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: smeger on Feb 22, '06 11:43:27AM

Unfortunately, this class of exploit can affect apps other than Safari, so turning off safe files isn't a complete fix. Neither is moving Terminal, because there are other programs on your computer that will run something for you.

I've updated Paranoid Android to handle this class of exploit. It's a pretty heavy solution, so I only recommend it until Apple releases a fix. More details here.



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: houplagrundle on Feb 22, '06 02:34:44PM
Renaming terminal stops it -

I added a letter to the name and then tested it out with the vulnerabilty test at http://secunia.com/mac_os_x_command_execution_vulnerability_test/

I can still open "safe" files automatically and not be vulnerable...

[ Reply to This | # ]

Avoid a security vulnerability in Safari
Authored by: solipsism on Feb 22, '06 07:27:10PM

I renamed the Terminal.app, would it also be prudent to alter the permissons so that my regualr user account can't execute Terminal.app.



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: curmudgeon on Feb 23, '06 01:06:33AM
Good ol' Firefox displays a dialog:
You have chosen to open Secunia.mov.zip
which is a PC ZIP Archive
from http://secunia.com
what should Firefox do with this file?
and then offers to save it or open it with a chosen app.

[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: mark hunte on Feb 23, '06 10:42:59AM
Good ol' Firefox displays a dialog: You have chosen to open Secunia.mov.zip which is a PC ZIP Archive from http://secunia.com what should Firefox do with this file? and then offers to save it or open it with a chosen app.
So then you choose to unzip it with Stuffit or what ever, and the double click the .mov file... same result.

---
mh

[ Reply to This | # ]

Avoid a security vulnerability in Safari
Authored by: vsmith1 on Feb 23, '06 05:58:42AM

I would also assume that it would be a good thing to do the same in Omniweb which has the same feature.

Vince



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: n8gray on Feb 23, '06 04:08:40PM

Perhaps somebody should write a folder action that strips the 'usro' resource from files (and maybe the creator code for good measure). Then you could attach it to your downloads folder, set it to activate for any newly-added file, and this sort of attack would be neutralized.

Does anybody know a scriptable way to hack resources? There's Rez and DeRez...



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: mark hunte on Feb 23, '06 05:19:45PM

I think some one already did a script here.

http://forums.macosxhints.com/showthread.php?t=51854

---
mh



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: n8gray on Feb 24, '06 11:07:20AM

The only script I see there is one that deletes the entire resource fork from every file. This will break any file that relies on having a valid resource fork! We need something that only deletes (or replaces) the usro resource. AFAICT, for somebody who understands the APIs involved this shouldn't be a terribly hard thing to do.

Unlike the other solutions out there (rename or move Terminal.app, delete the whole resource fork, etc) this would have extremely few, if any, unintended consequences.



[ Reply to This | # ]
An Terminal Open Stops execution of Proof of Concept
Authored by: amutti on Feb 24, '06 06:09:18AM

I always have my terminal open. Maybe this is a no brainer, but if you have the terminal open the proof of concept doesn't work . . . .

I'm not sure if this gives anyone more protection, but I didn't read it anywhere so I figured I post it.



[ Reply to This | # ]
Not for me!
Authored by: hamarkus on Feb 24, '06 08:41:30AM

The exploit works for with the Terminal beirg open.



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: nirsof on Feb 25, '06 09:27:46AM

The problem with Safari is actually problem with shell scripts and the Terminal, which will execute theme without any warning.

There is a simple fix that disable this unsafe feature of the terminal, called Safe Terminal.



[ Reply to This | # ]
Avoid a security vulnerability in Safari
Authored by: mayaahh on Feb 28, '06 01:59:00AM
There is a simple fix that disable this unsafe feature of the terminal, called Safe Terminal.
And according to the developer, this act only on Terminal.app so others app needing execute script will be OK, cron first, or Fink commander etc

[ Reply to This | # ]
Latest Security Update fixes this
Authored by: houplagrundle on Mar 01, '06 11:41:55PM
Security Update 2006 001

fixes it.

Safari now says "secunia.mov contains an application, do you want to download it?"

And doesn't run the acript

[ Reply to This | # ]

Latest Security Update fixes this
Authored by: houplagrundle on Mar 01, '06 11:50:30PM

Well it makes you aware that Secunia.mov contains an application,
but if you forgot and double click on Secunis.mov then it runs the script.



[ Reply to This | # ]
Latest Security Update doesn't help
Authored by: hst on Mar 02, '06 01:57:40AM
Security Update 2006 001 definitely doesn't help at my mac. The secunia.mov-script is executed after downloading the zip-file and double-clicking the extracted file Secunia.mov . I'll stay with safer terminal.

[ Reply to This | # ]
Security Update makes it warn you
Authored by: hayne on Mar 02, '06 11:47:23PM
The security update makes Safari warn you when you download something that is actually an executable even though it appears (at first glance, but not under close inspection) to be something else (e.g. a movie or an image).

I.e. the security update does not solve the problem of applications (or shell scripts) masquerading as something else. It merely stops the automatic execution of these applications when you download them. You get a warning and the application (or shell script) gets downloaded to your disk. If you then later go and double-click on that file, it will still execute - but that is your own fault.

Sure it would be much better if it was impossible for applications to hide their true nature, but we are not there yet. If you get a warning about something you are downloading being an application executable and you weren't expecting it to be an application, then you should heed the warning and stop downloading it.

[ Reply to This | # ]