Slashdot Mirror
Mac OS X Trojan Horse Infects MP3s
frequnkn writes "The Mac News Network reports that Intego has anounced an update to their anti-virus app for snagging the first Mac OS X Trojan horse, MP3Concept (MP3Virus.Gen), which exploits a weakness in Mac OS X where applications can appear to be other types of files."
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8 &oe=UTF-8&safe=off&frame=right&th=631707378ffe9292 &seekm=blgl-5D750C.02150821032004%40news.bahnhof.s e#link6
It appears that this is merely a proof of concept virus, hence, it is utterly benign. It was not made with any malicious intent, but to demonstrate one way that OS X could be exploited. The discussion group is concerned with making OS X more secure, not less.
Somehow, Intego got wind of it and blew it out of proportion, but I suppose it is theoretically possible that future viruses could be modeled on it. However I'm sure that Apple could, even more quickly, release a security update that fixes this.
Somebody on macnn.com pointed out this: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8 &oe=UTF-8&safe=off&frame=right&th=631707378ffe9292 &seekm=blgl-5D750C.02150821032004%40news.bahnhof.s e#link6
The resource fork is a remnant of the pre-OS X days. Pre-Mac OS X files, including applications, had two "forks": data and resource. When Mac OS X was created, it had the ability to run its own native applications, as well as two types of "Carbon" applications, Carbon being an API that allowed portability of applications using a subset of the old Mac OS programming APIs. One type of Carbon application, CFM, uses a resource fork for, among other things, file metadata. One of these pieces of metadata is something called Type and Creator. "Type", in this case, is set to APPL, and thus identifies itself as an application. While OS X decides to display the file as an MP3, the launching behavior is that of an application - just an oversight. The issue I was referring to was the resource fork must be kept intact in order for the file to still work - and any type of binary transfer WITHOUT special handling or compression (e.g. StuffIt, MacBinary, etc) will strip the resource fork and render this little "trojan" useless.
Also, if you knew the first thing about Mac OS X, you'd readily admit that the design philosophy and fundamentals of the OS do make it far, far more secure than, say, Windows.
It's not executed when you open it in a music player, it's executed when you open it in Finder.
.mp3 extension; apparently the HFS+ filetype takes precedence over the file's extension on OS X.
.zip file with Mac metadata extensions, an xtar archive, a MacBinary file, etc., then decode it, then double-click the MP3 inside. Since there is basically no legitimate reason to encode an MP3 with one of those archivers when transmitting it over the internet, this trojan is extremely easy to avoid; don't double-click MP3s that were extracted from Stuffit archives and similar places.
.zip with a password supplied in the e-mail and then running the contents to enable a worm to spread, so it's not entirely implausible. I'd like to think that Mac users have a higher average intelligence when it comes to virus safety, but I'm not too confident.
I haven't looked at this trojan, but I participated in a theoretical discussion of the possibility on usenet a couple of weeks ago (interesting timing, that) and the theory isn't that strange anyway.
The way it works is that it's actually a full-blown application. It's a Carbon CFM application, which is stored as a single file. There's a resource in the resource fork of the file which tells the OS where the actual executable code can be found; this allows the application's code to be embedded inside a larger chunk of data. The whole thing is then typed APPL with the HFS+ metadata filetype, but given a
If you open the file from your music player, it's a real MP3 that just happens to have a bunch of junk (trojan code) in an ID3 tag. It plays, nothing else happens. If you double-click it in the Finder, though, the Finder sees that it's an application and launches it, and then you're doomed. The app can do whatever it wants at that point. Presumably one of the very first things it does is open itself with your MP3 player so as to give the appearance of functioning like a regular MP3 file, and then it can go around infecting or deleting files at will.
This isn't a particularly dangerous trojan. Because of the dependence on HFS+ metadata and resource forks, the app can't be transported raw, it has to be encoded. So you absolutely cannot be infected by double-clicking an MP3 you got from Kazaa. You have to download an archive file, like a Stuffit archive, a disk image, a
For a successful internet worm to result from this, the recipients have to do two steps. First they would have to decompress the file that was sent to them, then they'd have to find the results and open it. Of course, we know from the example of Windows worms that enough users will go through the trouble of opening an encrypted
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
Utterly wrong. This is a CFM executable with no hidden extension. Double-clicking on it from the Finder will execute it, but dragging the file on to iTunes will only play the MP3 stream inside the file. Mail.app, however, correctly identifies it as an executable when you try to open it from inside an email.
The file is a CFM application. As others have pointed out, this means that it has a resource fork which it needs in order to be able to run. Thus, it must be downloaded as a compressed file. If the resource fork is stripped, it is harmless, as the payload will never be executed.
Its name ends in ".mp3", and the included icon is copied from an iTunes MP3 file, but its type code is APPL, an application. The data fork is a valid MP3 with PowerPC executable code inside the ID3 tags. When given to iTunes or another MP3 player, it simply plays the included sounds without executing code. When double-clicked on from the Finder, the surrounding bits of MP3 file appear to be ignored and the code is executed. The payload for the proof-of-concept displays a dialog box, then tells iTunes to play the file itself, presumably via AppleScript.
When double-clicked, it shows up in the dock as an application, though this could be suppressed in an actual hostile trojan just like many utility programs do. In the Finder, if one is using column view, it is identified as an Application instead of an MP3 File, and its icon is shown instead of a QuickTime-style playback bar for previewing the contents.
In terms of an actual exploit, the only thing going on that is even possibly questionable at an OS level is the presence of other stuff in the data fork before the Joy!peffpwpc tag. I am not certain if this is allowed in the definition of what a PEF executable is supposed to look like. Aside from that, there is nothing else that is tricking the OS into doing something it shouldn't do, only legally included information that is deceptive to a user who is not looking carefully at things.
NeXT did it for a good reason:
.app directory so all the resources, bitmaps, and supporting files are in that one directory. That is why I can reinstall OS X and have MS Office X and all my other applications still work without reinstalling everything. I suppose they could still do fat binaries as well if they ever decided to do so.
NeXTSTEP ran on four different hardware platforms and had fat binaries. Within the foo.app directory, there'd be foo-moto, foo-386, foo-sparc, and foo-hpux binaries. The OS would then attempt to execute the appropriate binary for the hardware platform the OS was running on.
OS X uses the
I tried every decent and legal way I could think of to resolve the issue w/the business before I rented the chicken suit
The Intego Virus Barrier software just flags as "infected" any CFM executable whose name ends in a common file extension... which is why it STUPIDLY flagged as viruses the BMP, PCX and PNG plugins for Photoshop Elements. Which means it does not even check for a dot and something else before the file extension.
Proof (jpg)
Can you say "crappy" ? I'm sure you could.
Maybe we deserve this world ?
Sorry to burst your bubble, but the whole 'app is really a directory' thing is a SOLUTION to the 'resource fork' storage problem. And it allows for cleanly implemented multi-platform 'fat' binaries. Apple's Classic fat binaries were kludgy, the CODE resource fork held the 68K binary and the data fork held the PowerPC binary, hardly extensible.
I've got an OSX install on purely UFS, and sure enough, it allows you to pack x86 and PPC binaries (or multiple PPC/X86 binaries, for optimization/bitness) into the same *.app so you can have one application file that executes on multiple architectures. It might not be Apple's hacked-up old kludgy way to get a 'fat binary' but it's effectively the same result but done MUCH cleaner and capable of living on many diverse file-systems.
Imagine how cool it would be to have ONE shared 'applications' folder mounted read-only on all your clients, the x86 clients execute the x86 code from camino.app and the PPC machines execute the PPC code from the same place. It would be an administrator's utopia!
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails