Comments on: Doorway to Mac Viruses?

By: Katie

Katie — Sat, 10 Apr 2004 00:32:48 +0000

That won’t stop people who have a slight clue from going into the “Get Info” option and changing the default app. I did that last night with some text files that had gotten classified as Debugger documents or some nonsense in the transfer of data from Q to Harumi. I regularly download files the computer thinks should be opened with a completely irrelevant program, and the “cannot open” error message, until now, has just meant that somebody made a mistake somewhere up the line and it’s up to the user to live with it, whine about it, or fix it. This might not actually unleash the terror (I know Macs better than your average bear, but I’m only at about 85% when it comes to data forks and the like), but it’s unnerving to think that in this case, it’s possible that somewhere along the line, savvy could get you into a mess instead of out of it.

(Please correct me if I’m way off base.)

By: Kelson

Kelson — Fri, 09 Apr 2004 22:49:07 +0000

Thanks for the analysis. The article and press release gave the impression that Finder was fooled: “OS X’s Finder application… doesn’t see the Carbon code and launches the malicious file.” It is interesting that it effectively hides the code from Unix-based tools, though. (I’m surprised no one at Apple has updated file to look at both forks.)

It seems to me now that Carbon is only necessary if the virus writer wants to hide the fact that the system has been infected. An older-style spoofer that pops up a fake error message justifying the lack of audio/video goodness could be done using Cocoa, but keeping the data fork “clean” makes it possible to hand real data off to the expected application.

Now that I know a bit more about this, I have an idea that might mitigate it. Since Mac OS X actually uses file extensions (which I think is a step backwards, but having worked in a mixed environment full of non-technical people, I can understand why), just set Finder up to pop up a confirmation notice if the file type and the extension don’t match: “The application you are trying to run is named as an mp3 file. Are you sure you want to start it?” Sure, the next variation could drop the extension entirely and still use a fake icon, but at least there will be one less avenue for social engineering.

By: Brion

Brion — Fri, 09 Apr 2004 21:03:13 +0000

Just a little nitpick; Finder is not fooled into thinking it's an MP3 file, but correctly identifies it as an application. The application embeds the iTunes MP3 file icon, though, so unless you're looking it's easy for the user not to notice. The interesting thing about it though is that the Unix 'file' command will identify the file as an MP3, and MP3 players will happily play the file; this is because the data fork (where the MP3 data goes) is actually not used in classic-style Mac applications -- the launcher code is stuffed in the resource fork along with the icons and whatnot. This also means that the trojan will be stripped out if the file is transferred without carefully preserving the file type and resource fork. (The proof-of-concept is distributed in a StuffIt archive.) There's also nothing Mac OS X-specific about this; it runs on Mac OS 9 too, according to the readme. Every version of Mac OS back to 1984 has been susceptible to the same "attack." This trojan style is pretty much inherent in mixing applications and documents together in the filesystem, using the same mechanism to 'open' them, and not sandboxing unknown applications. (I don't care if a trojan is stopped from changing my OS if it can still access or delete all the documents and e-mail on my single-user machine. Wasn't Java supposed to save us from the scourge of untrusted programs?)