Yes it is true, it is theoretically possible to write a virus that would affect Macs. Whether Macs have as many vulnerabilities as Windows or not remains to be seen (and unless Apple catches a really lucky break probably never will). Mac OS X is a UNIX based operating system, and UNIX, though very secure, is not impervious to attack.

The specific "Trojan horse virus" which Frank is referring to is a little misleading however. Someone on a newsgroup created a proof-of-concept that was not itself a virus, but demonstrated a possible way that someone MIGHT be able to create a Macintosh virus. One antivirus company saw this and sent out a big alert to all their enterprise customers, which then triggered a lot of media attention, which in turn forced all the other anti-virus companies to release patches. Of course all these patches do is prevent the proof-of-concept demonstration from running, and would not protect against any similar, more insidious application.

The weakness they found is actually a byproduct of Apples attempt to be more compatible with Windows. Traditional Macintosh files have two invisible 4 digit codes associated with them: The Type Code indicates what type of file it is, and the Creator Code indicates what application created it. This metadata (or data about data) allows the Mac to do things like have different image files open in different applications even though they were saved in the same format. Unfortunately the file systems used in most operating systems – including standard UNIX, Linux and Windows – do not have any support for this metadata. Instead, most operating systems rely on a file name extension (like .gif, .exe or .doc) at the end of each file name to tell you what the file is. In order to increase compatibility with these operating systems Apple made OS X enforce the use of file name extensions in addition to the Type and Creator codes.

The Trojan horse in question is an MP3 file which does in fact contain an actual song, but also has a small application hidden in the file header where MP3s normally store information like title, composer, album, etc... Because the file has a .mp3 extension on it's name the Mac OS displays it with an mp3 icon, so it looks like it's a standard mp3. However, the file's Type Code indicates that it is an application, so when you double click on the file it executes itself. In the case of this proof-of-concept a dialog box pops up indicating that the program executed, and then iTunes opens and plays the music file. Turning this concept into a virus may be possible, but it would not be terribly easy or effective, so it not currently considered a very high risk. For one, the file must make it onto the person's computer with its metadata intact, and since emails usually pass through several servers that do not support this information, Type and Creator Codes are often stripped from attached files which would render the virus inactive. And if the virus did manage to get on your system, and you chose to open it, then it still wouldn't have permission access to your system files.

The bottom line is that Mac users shouldn't be complacent, but the situation isn't nearly as dire as some of the media tried to make it. Perhaps Microsoft is right and there would be more Mac viruses if there were more Mac users, but in the end that almost doesn't matter. Apple isn't going to increase its marketshare by 50% overnight, and untill they do Mac users get to feel a little safer.

On a related but completely different note, both Mac OS X Tiger, set for release late this year, and Window's Longhorn OS, expected to come out sometime in the 2006-2007 timeframe, are rumored to have expanded support for metadata. I for one am hoping that this will mean the end of file name extensions during my lifetime. If you're interested, there is a nice article that talks about metadata in general, and specifically about its implementation in the Mac OS, at I found it some time ago, but I think it's still relevant today.

Jeremy Stoller
Senior Graphic Artist
California Science Center
(213) 744-2532
[log in to unmask]