I think Smircle's post about this trojan horse is excellent, but I'd like to post a critique. The subject is maybe more important than most things we discuss in this forum.
Quote:
Originally posted by Smircle
I just looked into the thing, and it is a valid trojan.
The executable code is in the data fork (like it always has been since the introduction of PPC), the icon shown by the finder is in the resource fork.
The "high-concept"-trick with this trojan is that the data fork starts off with a valid mp3-header, followed by a PEFF-code segment starting off at position 64 in the data fork which in turn is followed by the mp3 data.
The mp3 file format contains information as different chunks. PEFF also allows code in segements. If you are clever, you can interleave code and mp3. This allows the file to be played as an mp3 without any noise to reveal the true identity, but launched as an application.
The code is only executable because the 'cfrg'-Resource allows executable chunks to start at an offset in the byte stream. The first member in this resource is located at 64 bytes - this is where the system jumps into if you launch it.
This kind of virus could have been engineered years ago - since the advent of Carbon 1.1 (not because Carbon is insecure, but because it introduced the 'cfrg'-resources) on MacOS 8.6.
The application code is in the General encapsulated object (lines starting with === denote ID3-tags, so it is in a tag). Conveniently, iTunes does not show the existance of GEO-tags...
Yeah, it's a trojan all right. A friendly one, but a valid one nonetheless.
The blame lies squarely at Apple.
- iTunes should - under no circumstances - play anything that identifies itself as an applications. But it does and this is wrong, because it allows users to play this from the web, then store it and double click it one day. This would not be the case if it did not play in the first place.
One thing to note: downloading the file from the web will result in a harmless MP3 file that cannot run as an application, because the resource fork, required to execute the app, will be stripped from the file. The only way this Trojan Horse can be transmitted intact is either in an HFS-friendly archive, such as a StuffIt archive, or by copying it from a mounted HFS or Apple File Sharing volume. This fact really limits the distribution potential of the viable Trojan Horse.
It is not relevant, in my opinion, whether iTunes does or does not play an 'APPL' type file, because there are many more formats that could contain this exploit, and making all relevant applications check would require an entire update to almost all existing applications. Besides, third party applications would also have to check, and there are likely to be quite a few that wouldn't bother.
The better solution, again in my opinion, would be for the Finder and Apple's Launch Services to check the "magic" bytes at the beginning of the data fork of any application it is about to launch. If the magic bytes identify the file as a valid data format (MP3, JPEG, TIFF, etc), a warning could be issued to the user: "The file is actually an application, are you sure you want to launch it?" Or, more securely, the system could refuse to launch any application containing a valid magic sequence, and instead open the file with the relevant application, as no harm is done by opening the data file and viewing or hearing it. In fact, the latter action would be entirely what the user expects, and would not disrupt the current Mac OS user experience.
Quote:
- The Finder should mark each and every piece of software it would launch. Including AppleScripts, shell scripts, Carbon and Cocoa apps.
This places too much responsibility on the user: novice user's probably won't understand the difference between a marked and an unmarked file as it relates to whether or not they should double click the icon.
Quote:
- The CFM-Launcher disregards the Unix executable bit (chmod -x and you still can launch it). I can't figure out why - exept for the notable disregard inside Apple of anything Carbon. Hell, the NeXTies are too lazy to even look after security-relevant problems.
The executable bits of CFM apps, since they can operate in an OS 9 or OS X environment, really should be ignored. OS 9 does not have a concept of whether a file is executable other than the file's type and contents. If CFM application executable bits were respected, a CFM app could be copied to an OS X volume with the executable bits turned off, which would render the app inoperable until the executable bits were repaired. This would confound most novice users.
Quote:
Outlook:
the same trick could be employed with every "chunky" file format. TIFF comes to mind, as well as QuickTime (we all never double click QuickTime .movs, right?), and... AAC. Apple better move fast to do something about it.
Or any format that doesn't care if there is extra information at the end of the file.
Quote:
A further version could contain code that doctors existing mp3-files to become infected, thus spreading on your disk.
Besides the obvious "erase the home directory", a boosted version could employ AppleScript to read your contacts from the Adress book and send spam mails via Mail.app. This is the exact thing we have seen on windows for years now.
Okay, I'll level with you. I didn't write the critique. It was written by an extremely close relative who knows a lot more than I do, but doesn't have time to engage in these discussions.
What's ironic is that the Finder's Find function is *THIS* close to being able to be the antidote to this type of trojan horse.
Find:
Kind is Application
Extension is (NOT) app
We're missing the ability to say 'is not', only 'is'. If Apple added that one little thing, then the Finder would already have the ability to find the buggers easily.
What's ironic is that the Finder's Find function is *THIS* close to being able to be the antidote to this type of trojan horse.
Find:
Kind is Application
Extension is (NOT) app
We're missing the ability to say 'is not', only 'is'. If Apple added that one little thing, then the Finder would already have the ability to find the buggers easily.
Comments
He got it from http://www.danasoft.com/
It's completely unrelated to this discussion. Back on topic, please.
Originally posted by Smircle
I just looked into the thing, and it is a valid trojan.
The executable code is in the data fork (like it always has been since the introduction of PPC), the icon shown by the finder is in the resource fork.
The "high-concept"-trick with this trojan is that the data fork starts off with a valid mp3-header, followed by a PEFF-code segment starting off at position 64 in the data fork which in turn is followed by the mp3 data.
The mp3 file format contains information as different chunks. PEFF also allows code in segements. If you are clever, you can interleave code and mp3. This allows the file to be played as an mp3 without any noise to reveal the true identity, but launched as an application.
The code is only executable because the 'cfrg'-Resource allows executable chunks to start at an offset in the byte stream. The first member in this resource is located at 64 bytes - this is where the system jumps into if you launch it.
This kind of virus could have been engineered years ago - since the advent of Carbon 1.1 (not because Carbon is insecure, but because it introduced the 'cfrg'-resources) on MacOS 8.6.
id3info shows how the datafork is structured:
*** Tag information for virus.mp3
=== GEO (General encapsulated object): (virus)[virus.mp3]: application/octet-stream, 3221 bytes
=== TEN (Encoded by): iTunes v4.2
=== COM (Comments): (iTunNORM)[eng]: 00000A0C 00000000 000055AC 00000000 00000187 00000000 00007E8A 00000000 0000016D 00000000
=== TT2 (Title/songname/content description): Wild Laugh
=== TAL (Album/Movie/Show title): iMovie
*** mp3 info
MPEG1/layer III
Bitrate: 64KBps
Frequency: 44KHz
The application code is in the General encapsulated object (lines starting with === denote ID3-tags, so it is in a tag). Conveniently, iTunes does not show the existance of GEO-tags...
Yeah, it's a trojan all right. A friendly one, but a valid one nonetheless.
The blame lies squarely at Apple.
- iTunes should - under no circumstances - play anything that identifies itself as an applications. But it does and this is wrong, because it allows users to play this from the web, then store it and double click it one day. This would not be the case if it did not play in the first place.
One thing to note: downloading the file from the web will result in a harmless MP3 file that cannot run as an application, because the resource fork, required to execute the app, will be stripped from the file. The only way this Trojan Horse can be transmitted intact is either in an HFS-friendly archive, such as a StuffIt archive, or by copying it from a mounted HFS or Apple File Sharing volume. This fact really limits the distribution potential of the viable Trojan Horse.
It is not relevant, in my opinion, whether iTunes does or does not play an 'APPL' type file, because there are many more formats that could contain this exploit, and making all relevant applications check would require an entire update to almost all existing applications. Besides, third party applications would also have to check, and there are likely to be quite a few that wouldn't bother.
The better solution, again in my opinion, would be for the Finder and Apple's Launch Services to check the "magic" bytes at the beginning of the data fork of any application it is about to launch. If the magic bytes identify the file as a valid data format (MP3, JPEG, TIFF, etc), a warning could be issued to the user: "The file is actually an application, are you sure you want to launch it?" Or, more securely, the system could refuse to launch any application containing a valid magic sequence, and instead open the file with the relevant application, as no harm is done by opening the data file and viewing or hearing it. In fact, the latter action would be entirely what the user expects, and would not disrupt the current Mac OS user experience.
- The Finder should mark each and every piece of software it would launch. Including AppleScripts, shell scripts, Carbon and Cocoa apps.
This places too much responsibility on the user: novice user's probably won't understand the difference between a marked and an unmarked file as it relates to whether or not they should double click the icon.
- The CFM-Launcher disregards the Unix executable bit (chmod -x and you still can launch it). I can't figure out why - exept for the notable disregard inside Apple of anything Carbon. Hell, the NeXTies are too lazy to even look after security-relevant problems.
The executable bits of CFM apps, since they can operate in an OS 9 or OS X environment, really should be ignored. OS 9 does not have a concept of whether a file is executable other than the file's type and contents. If CFM application executable bits were respected, a CFM app could be copied to an OS X volume with the executable bits turned off, which would render the app inoperable until the executable bits were repaired. This would confound most novice users.
Outlook:
the same trick could be employed with every "chunky" file format. TIFF comes to mind, as well as QuickTime (we all never double click QuickTime .movs, right?), and... AAC. Apple better move fast to do something about it.
Or any format that doesn't care if there is extra information at the end of the file.
A further version could contain code that doctors existing mp3-files to become infected, thus spreading on your disk.
Besides the obvious "erase the home directory", a boosted version could employ AppleScript to read your contacts from the Adress book and send spam mails via Mail.app. This is the exact thing we have seen on windows for years now.
Okay, I'll level with you. I didn't write the critique. It was written by an extremely close relative who knows a lot more than I do, but doesn't have time to engage in these discussions.
Find:
Kind is Application
Extension is (NOT) app
We're missing the ability to say 'is not', only 'is'. If Apple added that one little thing, then the Finder would already have the ability to find the buggers easily.
Find:
Name Contains .mp3
Kind Is Application
Search
Originally posted by Kickaha
What's ironic is that the Finder's Find function is *THIS* close to being able to be the antidote to this type of trojan horse.
Find:
Kind is Application
Extension is (NOT) app
We're missing the ability to say 'is not', only 'is'. If Apple added that one little thing, then the Finder would already have the ability to find the buggers easily.
CFM apps don't have the .app extension anyway.