Apparently a security firm has discovered a way to trick Mac OS X into running a trojan horse. The technique involves creating a data file, but embedding a Carbon program in it. (Carbon is a programming interface aimed at making it easy to convert older Mac applications to run on Mac OS X without switching into Classic mode.)
According to Intego, Finder will see only the file type data display a spoofed icon identifying the file as (in their example) an MP3, but actually double-clicking on the file will cause the OS to notice the program code and run it. Their proof-of-concept code runs itself, then opens the file in iTunes in order to avoid looking suspicious.
This is very similar to a (fixed, but still present in a zillion unpatched systems) bug in Internet Explorer for Windows that was exploited by many mass-mailing viruses. In that case, IE would decide whether a file was safe by checking the MIME type sent by the server, then use the file extension to decide how to load the file. Viruses would generate messages embedding supposed MIDI files that Outlook would try to play, but instead of handing it to a MIDI player, it would ask the OS to open the file. Without the MIME info, Windows would see it was a program file and run the virus.
If this is confirmed, it will probably not be a vector for e-mail viruses, because the standard mail and web apps for Mac OS X don’t automatically run things the way Outlook, Outlook Express and Internet Explorer do.
No, the real danger will be viruses that spread through peer-to-peer file sharing networks. Download a supposed MP3 off of Gnutella, open up your music folder, double-click on it, and you’re infected.
Apple has said they “are aware of the potential issue… and are working proactively to investigate it.”
(Why is this news? Because it’s Apple, and because it’s so similar to a popular virus vector in Windows. Exploitable vulnerabilities are found so often in Windows I hardly blink.)
Updated slightly based on some real analysis (see comments).
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?)
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.
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.)