Easy Answers:
Turn off the "Open Safe Files after Downloading" in Safari.
Be suspect of all unknown attachments.
And, the big one for me - check suspect files using get info to make sure that they really are who they say they are.
--------------------------------------------------------------------------------
(this article is from "Tidbits" -
http://www.tidbits.com/tb-issues/TidBITS-818.html#lnk5)

Of Files, Forks, and FUD by Matt Neuburg <matt@tidbits.com>

As a level-headed, rational reader of TidBITS, you have, I trust, resisted being swept away on the wave of fear, uncertainty, and doubt spread this past week with regard to the latest variety of Mac OS X security holes to gain wide attention (see Geoff Duncan's "Significant Safari Exploit Discovered," elsewhere in this issue, for more details). The mass media, not unexpectedly, have eliminated from their "reporting" all historical perspective and technical details in favor of block-busting headlines whose actual semantic content ("Mac OS X has viruses!") is on a par with an inarticulate scream. And then there are the usual fear-mongering press releases from self-interested companies. Let us, however, ignore the hype and consider the facts.

Open Sesame -- Those facts mostly involve how documents and applications are associated in Mac OS X. When you look at a document in the Finder, it has an icon supplied by the application that opens it. When you double-click the document, that application is launched and opens the document. How is this association maintained?

Back in the days of Mac OS 9 and before, the answer involved metadata invisibly stored in the file system and looked up through an invisible database. When Mac OS X emerged, though, Apple set out to supersede this architecture with those obnoxious little file extensions that appear, visibly or otherwise, after a period in the name of the file, along with a complicated series of strategies for locating the associated application.

< http://db.tidbits.com/ getbits.acgi? tbart= 05415>
< http://db.tidbits.com/ getbits.acgi? tbart= 06584>
< http://arstechnica.com/ reviews/ os/ metadata.ars/ 8>

Apple thus suppressed an elegant method of performing document-application associations, one that worked reliably (barring the occasional need to "rebuild the desktop" when the association broke down) and was invisible to the user, in favor of an ugly and often unpredictable system of incorporating a file's type into its name merely because that's how other operating systems do things. Except that they didn't completely suppress the earlier method; instead, they incorporated it into an uneasy Jekyll-and-Hyde alliance. For one thing, a file left over from the pre-Mac OS X days might well have no filename extension. So a file might have type/creator metadata, or a filename extension - or both.

But there's more. Consider the problem of a generic file type, such as pdf. Both Preview and Adobe Reader can open a .pdf, so which of them should open this particular .pdf file? You, the user, might answer that question on a one-time basis by dragging the file onto the desired application's icon in the Dock or the Finder. But what if you wanted to assign the file to one application or the other, so that it would always open with that application when double-clicked in the Finder?

For reasons that aren't entirely clear to me, Mac OS X does not use the type/creator metadata to handle this situation. Instead, Apple instituted a slot in the resource fork - the 'usro' resource - where the user's custom file association is stored. Thus, when you use the Open With pop-up menu in the Finder's Get Info dialog, you're actually setting the file's 'usro' resource. It's possible for a file to end up with all three - a 'usro' resource and a metadata creator code and a filename extension.

< http://db.tidbits.com/ getbits.acgi? tbart= 07516>

Exploring the Exploitation -- The trouble, it turns out, is that it is possible to misuse these pieces of information to generate a conflict. Such a conflict lies at the heart of the current set of security exploits. When you download and expand the demonstration file created by Heise, what you end up with is a text file containing shell script commands; but the file has a .jpg extension and a bad 'usro' resource. The extension determines the document icon (on my machine, it is a JPEG icon that comes from Preview), but the 'usro' resource associates the file with a different application, namely the Terminal. You can tell that in fact this is a Terminal document by examining the file's Get Info dialog in the Finder.

< http://www.heise.de/ security/ dienste/ browsercheck/ demos/ safari/ Heise.jpg.zip>

The fact that this inconsistency is possible is probably a bug in the system. Theoretically, the system ought to be able to detect that the 'usro' resource is invalid. When I test the user creator-assignment mechanism, I observe that the file, along with a 'usro' resource, gets an 'icns' resource which is labelled "Binding Override" and presumably is intended to be the document icon from the newly assigned creator. For example, GraphicConverter's JPEG icon is different from Preview's JPEG icon. But Terminal has no JPEG icon, because it doesn't open JPEG files; and besides, the exploit needs Terminal to treat the file as text, not as JPEG. So the Heise file has no 'icns' resource, and this should alert the system that something's wrong.

Stuff and Nonsense -- The fact that the exploit involves a .zip file, which is expanded on your computer in order to generate the invalid document, is irrelevant. True, the document is expanded by either StuffIt Expander or Apple's own application, BOMArchiveHelper; but these applications play no important part in the story, as they are merely reproducing, correctly, the bad file that was handed to them in the first place. It is also true that the .zip file, internally, is in a special format; but the same thing would apply to any file with a resource fork.

The role of Safari in the story should also not be stressed unduly. It is true that if Safari's "Open 'safe' files after downloading" preference is turned on (which, for many reasons, it should not be), Safari will effectively open the downloaded file twice - once to unzip it, and once to open what it wrongly thinks is a nice safe .jpg file. But this is no different, really, from what you would do with the file in the Finder by double-clicking the .zip file and then the .jpg file.

It has also been observed that Apple's Mail suffers from the same behavior as the Finder - that is, when this file is sent to you as an email attachment, Mail shows you a JPEG icon (as well as the .jpg extension), but opens the file in the Terminal if you double-click it. However, I'm fairly sure that this is the same behavior as the Finder's, merely being displayed in another context.

Finally, there has been some misleading talk with regard to the fact that the file in question is an executable - it is a shell script, and its executable permissions are set so that when it is opened by the Terminal the script runs. That there is such a thing as a double-clickable executable shell script is nothing new; any text file with a .command extension and executable permissions will run in the Terminal when double-clicked, and this has always been true. (You might reasonably argue that it shouldn't be true, and you might also not have been aware of the fact that it is true; that's a different issue, which I'll come back to in a moment.) And the fact that an executable can be communicated as a compressed file is nothing new either; were this not so, it would be impossible to send someone else a compressed application. Some reports have stressed the fact that the file has no "shebang" line, but that is a red herring; the exploit works equally well whether or not the shebang line is present.

Conclusions -- My conclusion has two parts, and they both amount to an assertion that computer files, as Iago says of men, "should be what they seem, or being not, would that they might seem none."

In the first place, Mac OS X has never fully rationalized its complex scheme of document-application association, and now we see that there is in fact a bug in that scheme. Apple needs to get this straightened out, on the double, so that a file always looks like what it is.

Secondly, an executable, of whatever sort - from a Cocoa application bundle to a lowly executable shell script - is a very special kind of file, and it needs to be marked as such. Data that you read and code that you run are both files, but they are crucially different kinds of file; so executables should look and behave specially. Any file which, if merely opened, will itself run as code, should be "badged" in some prominent and suggestive manner. It might also help if the first opening of every executable were preceded by an alert. Apple did institute something like this after the URL scheme debacle, but they didn't go far enough - an alert appears the first time you launch an application by double-clicking one of its documents, but not the first time you open the executable itself - whereas the entire problem, as we now see, is that you might not even know that this is an executable. This, when Apple fixes things so that executables can't be disguised as JPEGs, will make the world a safer place.

(this article is from "Tidbits" -
http://www.tidbits.com/tb-issues/TidBITS-818.html#lnk5)