More on malicious code on the Macintosh


This isn't intended to scare people in the least. In fact, it's intended to inform, and if we were talking about Windows, there's no way that I could comment on almost every threat of Malware that comes up on the platform. However, on the Macintosh, I feel some responsibility to address these issues, especially as they relate to best-practices. The German site, heise online is reporting this morning about another potential threat to our fine platform, and another reason to seriously consider telling Safari not to "Open 'safe' files after downloading."

The description in the article is fairly technical (although amusing to the unix-inclined in our midst), but basically there are ways that the Macintosh can be fooled into disconnecting the icon of a file from the way that it determines how to open the file. This has been a problem on the Macintosh for many years, as there's always been the ability (even under OS 9) to use custom icons. However, in OS X, this problem has gotten a bit more interesting because of how the two issues are separated.

To determine which program to launch when a file is double-clicked (or opened automatically by Safari), the Finder first looks at the resource fork for the file (a holdover from OS 9 and generally not a spectacular idea on modern Macs) and if it contains instructions on which program should open the file, it listens to that. If a resource fork doesn't exist for the file, it doesn't contain that information, the application doesn't exist on your computer, then the finder falls back to looking at the extension on the file and uses the system's internal understanding of which file name extensions (like .jpg) go with which programs (like Preview).

To determine the icon to display, the same basic process is followed, except it looks for some metadata that is attached to the file in a different way (other than the resource fork) first and then falls back to the system table.

In the case of the example file from the site, the resource fork contains instructions to open the document using Terminal, the program that executes Unix commands. You can make Terminal open a file yourself as an example, just by selecting Get Info in the finder and then setting the Open With to be something other than the program it is now. In fact, you can set it up to be just about any program, it's just that Terminal is probably the most potentially destructive.

So, what should we or Apple do about this? On the user front, it's hard to say. Certainly, if you disable "Open 'safe' files after downloading" then the program will not run immediately upon clicking on it. However, the file still ends up on your disk with the icon (and extension) of a .jpg file and you're going to be likely to double-click on it, which is going to have the same effect as having Safari open it. I would suggest that, for now, unless you're very certain of the content, you take a good look (with Get Info) at any files that you download, especially if they arrive in .zip, .tar, or .dmg files. The reason for this special precaution on those types of files is that the resource fork is not understood by any other operating system than MacOS, and thus a normal .jpg file being downloaded as a .jpg instead of in a .tar, .zip, .dmg, or other wrapper (such as the old .bin or binhex) cannot contain a resource fork.

For Apple's part, I'd really like to see them tighten up the use of the Terminal as an application to open data files. Unlike any other part of the OS, it's particularly dangerous as data is executed as if it were user-typed instructions at the UNIX prompt, in whatever security mode that user may be in (which, for some people is likely to be administrator). By making all data files that are double-clicked or Finder Opened display an "are you certain"-style dialog (similar to the one that you get the first time you run a newly installed or downloaded application), the user would get a good opportunity to say "no" to shell programs like this, and at least be immune from a trojan that might not be recognized until it has done something destructive (you'll always notice it after the fact, as a Terminal window will open).

Thanks to MacDevCenter for this article that got me started on this topic this AM.

NOTE: As described in this article, I couldn't get the demonstration to cause my machine to execute the program without my intervention, despite having the "Open 'safe' files after downloading" option turned on. However, the threat may still exist in that form and it might be a good idea to turn off the convenience feature for now.