Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
eSnow said:
The res-fork contains a 'cfrg' (short for configuration) resource that tells the system that one code chunk is contained in the data fork starting at offset 64 into the data and having a length of 3215 bytes. The system reads this information and then opens the data fork and executes the code there. If the description in the 'cfrf' resource is not available, the trojan cannot be launched.


jpg might be fine, jpeg2000 is likely not. AAC and TIFF are likely also at risk, as is .mov. It is nothing special to .mp3, could happen with any file format that is structured and tagged.

So, This is my take. The MP3 spec allow users to add any kind of information to a file into 'containers' identified by the ID3 portion of the mp3. iTunes will parce the file looking for conatiners it knows (title, track, year, etc). They don't have to exist for iTunes to play the music track.

virus.mp3={
data-fork={ID3={title="Wild Laugh",rawcode={!@#$!@#$} album="iMovie",.....}musicdata={#######}}
res-fork={app. location={move over 31 characters in data-fork take next 8 characters}}
}

When iTunes see the file. It doesn't look at the res-fork at all. Looks in the ID3 tag to fill its own database, sees 'rawcode' and ignores its contents because it doesn't know what it means, finds music data and plays it.

When finder sees the file. It checks the res-fork. Sees the instructions for where the application binary is located in the datafork and runs that. Oblivious to ID3 and music data. (the code actually tells iTunes to open itself with the behavior explained prior) So, without the resource fork, the 'rawcode' ID is just fluff for every other mp3 app.

Do I get it now?
 
msconvert said:
Do I get it now?

Exactly. The neat part is in the interleaving between code and .mp3-data:

Normal mp3-file:
XXXXXX 11111111 22222222 YYYYYYYY....

infested file:

XXXXXX 1111111 VVVVVVVV 222222222 YYYYYYY....


(X: mp3-header, Y: mp3-data: 1 and 2: ID-Tags, V: viral code)

iTunes (and other mp3-players) start with the beginning of the mp3-header (XXXX), read it and the interesting ID-Tags and start playing the data (YYYY). Since the code is packaged as as ID-Tag, iTunes will not complain about a file format violation either.

The system is instructed by the 'cfrg'-Resource to jump right to the beginning of the V-chunk and execute the code it finds there, ignoring the rest of the mp3-File.

Really neat.
 
Doctor Q said:
Even if the Finder learns to give warnings, I've found that a lot of people will click OK in almost any dialog box, without reading it. If the Finder said "This is an unknown application from a suspicious source, disguised as a data file, with a misleading extension. OK to launch it?" they would click OK.
Of course, but that's exactly why the whole thing here is a non-issue. You could just send the virus as an app with an app extension and everything, it's useless to build mp3 files because people would launch apps sent by someone they know just as quickly as an mp3 file that gives you a weird warning message.
 
eSnow said:
You can't because 8.6 has no Unix underpinnings and detects executables by a different mechanism. The point is that the x-bit is an important security mechanism in Unix and disregarding it is a bad thing[tm].
Apple needs to look at it's state before launching a CFM-application like it looks at it before launching a MachO-app (not that it would have prevented this specific trojan, but maybe the next).

That really doesn't make any sense at all. a) it's trivial to set the unix and classic flags. b) If you want to be able to run carbon apps, you have to use the classic mechanism. c) The x-bit security mechanism is far from important when it comes to viruses.
 
eSnow said:
Exactly. The neat part is in the interleaving between code and .mp3-data:

[....]

Since the code is packaged as as ID-Tag, iTunes will not complain about a file format violation either.

The system is instructed by the 'cfrg'-Resource to jump right to the beginning of the V-chunk and execute the code it finds there, ignoring the rest of the mp3-File.

Really neat.

Exploiting the very feature that makes OSX so platform compatible/tolerant.

Slick.
 
"5 bucks says intego had a hand in this trojan directly or indirectly."

If you wish to know, check macbidouille/ hardmac, as we're to publish an exclusive interview with Intego CEO... in no time in English... already (in French) on macbidouille.com
 
You're right except that 'cfrg' is short for "code fragment" (resource type introduced with the CFM (Code Fragment Manager) with the first Power Mac to support Fat binaries (PPC and 68k in the same file))
All PPC applications have their code in the data fork. 68k applications had their code in the resource fork before CFM was introduced.

eSnow said:
The res-fork contains a 'cfrg' (short for configuration) resource that tells the system that one code chunk is contained in the data fork starting at offset 64 into the data and having a length of 3215 bytes. The system reads this information and then opens the data fork and executes the code there. If the description in the 'cfrf' resource is not available, the trojan cannot be launched.


jpg might be fine, jpeg2000 is likely not. AAC and TIFF are likely also at risk, as is .mov. It is nothing special to .mp3, could happen with any file format that is structured and tagged.
 
123 said:
Of course, but that's exactly why the whole thing here is a non-issue. You could just send the virus as an app with an app extension and everything, it's useless to build mp3 files because people would launch apps sent by someone they know just as quickly as an mp3 file that gives you a weird warning message.

It isn't a non-issue. Everybody knows / should know that unexpected Applications can be a threat. But data files, harmless, friendly, cute looking data files that only want to be opened? You must be paranoid!

Got the difference?

Oh and about that weird warning message. That's simply what this app does. It could just as easily mail random files to random people from the address book, send a copy of itself to everyone in said address book and then delete all your personal data. That is if you are logged in as a simple user..

On a side note every data format could be used this way. If it has no strange abuse-friendly headers it might simply look/sound like rubbish but who cares; broken files happen once in a while..
And even in such a case double-clicking could still result in a valid file of the appropriate type being opened thus keeping the cover intact.
 
eSnow said:
I just looked into the thing and there is no code in ressource forks. The executable is in the data fork - only the custom item is stored in the resource fork.

I stand corrected.

However, as is fairly widely known now, the resource fork is required to trigger the code in the data fork. As I said, it is highly unlikely that you'll ever be able to get a resource-fork-equipped MP3 file on your Mac in the first place. Without the resource fork, the .mp3 is non-executable.
 
eSnow said:
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.

True, but if iTunes is fixed (I agree it should be), what about all the other media players out there? This needs to be fixed by Apple, but this can't be the only fix.

- The Finder should mark each and every piece of software it would launch. Including AppleScripts, shell scripts, Carbon and Cocoa apps.

Hmmm. Yeah, I guess so. But then, I look at my files and I see all the Apps marked as such, all the scripts marked as such, etc. Although, only in column and list modes. Should Apple put something "around" the application icons in icon Finder mode? People got way too offended about how labels look ... and you don';t have to use those. How many cries of panic and disgust would Apple have to deal with if they introduced even a subtle effect to Application icons?

- 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.

Yeah, you shouldn't be able to launch a non-executable file. That's the whole reason for that flag (so you can keep "others" from executing apps without copying them elsewhere). But, on the other hand, one would expect that any mechanism for getting a resource-forked file onto your Mac would also be generally capable of chmod 755 on it. A valid complaint, but really off the topic here.

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.

Problem is, this isn't an Apple-only problem, except the "user might keep the file around thinking it's a valid MP3/MOV" angle.
 
space2go said:
It isn't a non-issue. Everybody knows / should know that unexpected Applications can be a threat. But data files, harmless, friendly, cute looking data files that only want to be opened? You must be paranoid!

Got the difference?
No. There isn't any.

1) Every carbon app can be made to look "harmless, friendly, cute" in Mail.app. Neither you nor Mail.app can tell the difference, the added "benefit" of the ID3 technique is minimal at best. In fact, if you want to write a virus that spreads quickly, it doesn't make a difference at all. It's therefore a non-issue.

2) Everybody knows/should know that you should read warning messages, think and act accordingly. You always get the same warning message, no matter how hard you try to camouflage the app/virus.

Oh and about that weird warning message. That's simply what this app does.

Misunderstanding, this is the message I'm talking about:

The attachment "LOL.mp3" is an application. Since applications can contain viruses or be harmful to your computer, be sure this attachment is from a trustworthy sender before saving or opening it.

Would you say it is reasonable to proceed if you get that message when you try to listen to an mp3 file that has been sent to you? My suggestion to Apple: change the trustworthy sender part, pretending to be from a friend is exactly what those viruses do. Probably more important than the whole trojan news story that has been blown out of proportion.

And even in such a case double-clicking could still result in a valid file of the appropriate type being opened thus keeping the cover intact.
You mean keeping the cover intact after deleting all personal data? 😛
I'm not convinced, the only new plausible strategy that the ID3 technique makes possible is stealth infection and distribution at glacial speed. And even if you manage to distribute some files like that (by user sent email), many infected computers aren't really "armed", the virus just sleeps in some files on some computers and can't be triggered. The whole exercise would be highly ineffective and extremely boring for the virus programmer -> proof of concept, nice, but essentially a non-issue.
 
123 said:
The attachment "LOL.mp3" is an application. Since applications can contain viruses or be harmful to your computer, be sure this attachment is from a trustworthy sender before saving or opening it.

Would you say it is reasonable to proceed if you get that message when you try to listen to an mp3 file that has been sent to you?

Simply put the thing in a .sit.

123 said:
The whole exercise would be highly ineffective and extremely boring for the virus programmer -> proof of concept, nice, but essentially a non-issue.

Have you ever looked at worms that spread in the windoze world?

Having the user open a password "protected" zip file with the supplied password by hand, navigating the resulting folder structure and then actually starting the damn thing (by hand again) is an example for the kind of help a worm may expect to get.
<sarcasm>
Of course you probably could get the same result with a mail like this:

Dear Sir/Madam I'm a virus.
Please forward me to every person in your adress book and join the spammer volunteers mailing list [1].
Thank you for your cooperation and have a nice day.
Yours sincerly, Joe Evildoer.
p.s. The person that forwarded me to you is an idiot.
[1] - subscription info
</sacrcasm>
Hoping for the receiver to save a sit to disk and then trying to open the automatically extracted content by simply double-clicking it is a far more valid strategy than the above.
 
7on said:
bah, has anyone used of opened this offending file?


Personally sudo has never settled right with me. Apple should rid the system of the command and only allow root access by logging in as root. Sure it'd be time consuming to delete an undeletable file, but it'd be worth it for the security.

Actually, it's more of a security risk for your system to be set up to allow root logins, which Apple disables by default. Sudo allows root (or "super user") privileges on an 'as-needed' basis. Other linux and unix-like systems offer this, too.
 
Jerry Fritschle said:
Actually, it's more of a security risk for your system to be set up to allow root logins, which Apple disables by default. Sudo allows root (or "super user") privileges on an 'as-needed' basis. Other linux and unix-like systems offer this, too.

Since sudo is equivalent to root logins (sudo bash), it is actually quite a risk. For example, OS X doesn't ship with a secure FTP server and I'm sure many users just send their password in plaintext when they connect to their computer from a remote location (I do, for example) or when they access their email (for which they often use the same password). Having a root account solves those problems because you never have to ftp as root or read emails as root. Even if you are ssh-ing into your account it's better because people don't know when you enter the root password, sometimes you do it after 10 minutes, sometimes you don't do it at all, whereas they always know that the first thing you enter when you open a connection is the sudo password and it's easy to figure it out after watching you a couple of times. You can also put it this way: Administrator users in OS X constantly use "a" root password and this is certainly not secure.

In order to get both types of security (against others and against yourself), you'd probably have to set up an admin account which you only use to sudo and remove yourself from the sudoers file.
 
For the reasons why sudo is more secure see my earlier post.

123 said:
Since sudo is equivalent to root logins (sudo bash), it is actually quite a risk. For example, OS X doesn't ship with a secure FTP server and I'm sure many users just send their password in plaintext when they connect to their computer from a remote location (I do, for example)

Surely you're not that silly. You've got to be making this up to make a point. If you would prefer to set about setting up an insecure telnet or ftp server on your mac, rather than just checking the "Remote Login" box under sharing and using the incredibly secure ssh/scp/sftp (for which there are free clients for every platform), then, well, honestly I am at a loss for words.


or when they access their email (for which they often use the same password). Having a root account solves those problems because you never have to ftp as root or read emails as root.

If the person is security challenged enought that they are logging in via plaintext, and using the same password for their login account and email, do you really think they will use a different password for root?

It's a false security -- it gives no security benefit, but adds an extra difficutly for the novice users. For the advanced user, if you really do believe it is safer nobody is stopping you from disabling sudo access and enabling root.

Even if you are ssh-ing into your account it's better because people don't know when you enter the root password, sometimes you do it after 10 minutes, sometimes you don't do it at all, whereas they always know that the first thing you enter when you open a connection is the sudo password and it's easy to figure it out after watching you a couple of times.

If the person is so dedicated to trying to crack your box that they are sniffing the network trying to steal a password, 99% of the computer world has lost already through inexperience. I would put to you that this is a very unusual situation.

There's a continuum to watch -- the more secure a system, the more inconvenient it is, and so the less likely people are to use it. A balance needs to be struck and this is what Apple has done.
 
stcanard said:
Surely you're not that silly. You've got to be making this up to make a point.
I'm not making this up, don't know why I should. There's no sensitive data on that computer and I'm educated well enough to know the risks.

If you would prefer to set about setting up an insecure telnet or ftp server on your mac, rather than just checking the "Remote Login" box under sharing and using the incredibly secure ssh/scp/sftp (for which there are free clients for every platform), then, well, honestly I am at a loss for words.
1) Many people do this. It's not widely known how sftp works, so they just check the FTP box. "loss for words"... get real.
2) There are only sucky clients on the platform unless you want to spend some money.
3) Also, sftp is a laughable concept. Now, if there was an auth-tls ssl FTP server bundled with OS X and free and good clients were available I could understand your reaction.

If the person is security challenged enought that they are logging in via plaintext, and using the same password for their login account and email, do you really think they will use a different password for root?

It seems you have no idea. People even use the same password on ebay and other web services, often transmitted in plaintext too. As for your question, you can enforce different passwords. Also, you can tell those people that it is extremely important that they don't use this password for anything else (play some sounds, flash the screen etc. when they enter the root pw, things people know from movies).

It's a false security -- it gives no security benefit
Of course it does, you don't log in with a root password (by which I mean a password that allows root login).

, but adds an extra difficutly for the novice users.
Why? It adds just enough difficulty to provide real security.

For the advanced user, if you really do believe it is safer nobody is stopping you from disabling sudo access and enabling root.
I'm not talking about the really advanced users. I'm talking about novices and about lazy people and about people like you who think logging in using a root password is good (even if they use ssh).

If the person is so dedicated to trying to crack your box that they are sniffing the network trying to steal a password, 99% of the computer world has lost already through inexperience. I would put to you that this is a very unusual situation.
Sniffing the connection is unusual? The tools are so easy to use, the average comp mag buyer has used them several times.

There's a continuum to watch -- the more secure a system, the more inconvenient it is, and so the less likely people are to use it. A balance needs to be struck and this is what Apple has done.
Yes, Apple has done something like that. But that doesn't mean sudo is better than a separate root login security-wise, which is the contention here, because it clearly is not.

As for sudo being more secure because you have to think about what you're doing... personally, I think this idea is completely overrated. How many times have you been saved by sudo? In my experience, I mostly run into those errors because I just forgot to enter sudo, not because I do something that normally wouldn't require root privilegies but now does in this very special case I haven't thought about (like being in the wrong directory and typing rm -rf *). So, the normal reaction to the error is: cursor_up ctl-a sudo enter. And a wrong sudo call ****s up the system just as bad.

So, again, in my opinion sudo should be disabled (at least for login users) and to give the novice and others an additional level of security, rm could be overriden to move files to the trash or a different directory which is cleared once every hour or so (I and many others are currently doing this anyway).
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.