[Developer]

Originally posted by wings_rfs:
Whatcha think?

Can't work. Some users might not have sufficient privileges to modify the app, or it might be physically impossible (apps on CD-ROM).

[Developer]

Originally posted by Kristoff:
But again, what's the point?

user double clicks pam_and_tommy.mpg and a dialog pops up:

"ALL YOUR BASE ARE BELONG TO US
Certifies that this application is safe.
Do you want to trust applications
signed by ALL YOUR BASE?"

How many people will actually read and comprehend vs how many will think "where's the pr0n?" as they click the "always trust" button.

It is basically the same safety mechanism as proposed by theolein and Millenium � a Warning message is displayed before an application is launched, however with the following advantages:

� users can principally trust all applications of certain vendors, or of all vendors whose identity has been verified, or of all vendors whose e-mail address has been verified etc. at their choosing. So their usually not annoyed by this dialog.
� administrators can flat out prohibit underprivileged users from running applications below the trust level of their choosing.
� since acquiring a certificate requires at least a valid e-mail address, it's more unlikely that someone would distribute malicious code signed, because it would make him better traceable.

[wings_rfs]

Originally posted by Developer:
Can't work. Some users might not have sufficient privileges to modify the app, or it might be physically impossible (apps on CD-ROM).

It *CAN'T* work??? Not even if Apple wrote the Finder to do this??? It certainly CAN work if Apple wrote the necessary code. I understand permissions, and to say a user needs the appropriate permissions to "modify" an application is true. But.... Apple can make it happen if they so choose. As for apps from a CD, well let them run without a check, or better yet, a Finder Pref that allows you to choose whether to be notified or not.

[Gavin]

I'm curious about exactly what damage could be done by a malicious program and what steps might be taken by the system to interfere with that. Say I have LittleBastard.app on my desktop and I run it, given that it is in my UNIX sandbox what's the worst it could do?

It can delete files in your home folder. it could save new files in your home folder. OK, that would piss me off but I wouldn't need to reinstall the OS or pay a technician.

Can it get outside your home folder? Maybe write something to your /Library/Quicktime components folder, etc. Are there any system or networking settings it could have access to?

Can it set itself to run on startup without my noticing? Can it keep me from easily removing it, like viruses do on windows?

It could probably send itself on to others. Find addresses in your address book. Perhaps put something in your outgoing mail queue.

Could it flood your network? Take your office down? Could it do what the blaster worm or other nasty win virus did, like repeatedly log me off the internet or force a reboot every 10 minutes?

I think a lot of these could be detected and stopped by the system.

It would presumably run in background, that is not showing in the dock. Why would a legitimate background process want to access your address book, open a network port, change settings or delete files? The system should pop up a dialog letting you know and asking for permission along the lines of the keychain. Some sort of trust level database.

Someone suggested you might be asked "application xx wants to access your address book, let it?"
How about:
"application xx wants to change a file that was created by another application, let it?"
"application xx wants to delete things, let it?"
"application xx wants to talk over the network, let it?"

You would only get asked the first time it happened so it wouldn't be too annoying. And maybe you could set the paranoia level so the system won't care if photoshop is managing it's cache, etc. Or perhaps there could simply be a suspicion algorithm based on creation date, background or not, known app. etc.

[besson3c]

Originally posted by Gavin:
Can it get outside your home folder? Maybe write something to your /Library/Quicktime components folder, etc. Are there any system or networking settings it could have access to?

Not that I know of, not without authenticating

Can it set itself to run on startup without my noticing? Can it keep me from easily removing it, like viruses do on windows?

It can put itself in your Login Items list. I'm not sure if you can put "faceless" scripts and things in there that won't bounce in your dock. I suspect that all user level apps appear in the dock, so no, I believe it would be noticed.

If it tricked you into authenticating, it could install itself somewhere where it would be a little difficult to find, but as far as I know the only sorts of places a virus could run from would be your StartupItems folder, Kernel Extensions, etc. If it didn't authenticate, it would be in your home directory somewhere. IOW, there are only a few places where the virus would be automatically executed from. It would be easy to remove this file if you knew where to look (easier than the Windows registry). It might scatter a whole lot of garbage files around the system, but they would be sitting dormant without the virus executable/daemon running

It could probably send itself on to others. Find addresses in your address book. Perhaps put something in your outgoing mail queue.

This is actually a little harder to do than you describe. OS X Mail can't be scripted to send attachments. The virus would have to create its own SMTP server, or enable Postfix and send mail this way.

Could it flood your network? Take your office down? Could it do what the blaster worm or other nasty win virus did, like repeatedly log me off the internet or force a reboot every 10 minutes?

It could do those sorts of things, but it would need to authenticate to install itself as a system daemon.

[utidjian]

Originally posted by besson3c:
Not that I know of, not without authenticating

If the user who receives the virus is the admin user it can write to /Applications without authentication. That means it can affect any of the apps in /Applications.

It can put itself in your Login Items list. I'm not sure if you can put "faceless" scripts and things in there that won't bounce in your dock. I suspect that all user level apps appear in the dock, so no, I believe it would be noticed.

A virus, by definition, attaches itself to a legitimate application or data file that is opened with a legitimate application. IOW it "infects" a host app or data file. In the example virus it was attached to a legitimate MP3. It won't show up in the dock except as iTunes. iTunes is noticeable... but only as iTunes.

If it tricked you into authenticating, it could install itself somewhere where it would be a little difficult to find, but as far as I know the only sorts of places a virus could run from would be your StartupItems folder, Kernel Extensions, etc. If it didn't authenticate, it would be in your home directory somewhere. IOW, there are only a few places where the virus would be automatically executed from. It would be easy to remove this file if you knew where to look (easier than the Windows registry). It might scatter a whole lot of garbage files around the system, but they would be sitting dormant without the virus executable/daemon running

A virus is near impossible to find unless you know exactly what file to look at and what "signature" it would have. That is what virus scanning software does.

This is actually a little harder to do than you describe. OS X Mail can't be scripted to send attachments. The virus would have to create its own SMTP server, or enable Postfix and send mail this way.

It is actually quite easy. I posted a link to such code in the "tout" thread.

It could do those sorts of things, but it would need to authenticate to install itself as a system daemon.

True. But viruses can be patient. If the user is the admin user it can write to anything under /Applications including things that are likely to ask you to authenticate such as Keychain Access.app and System Preferences.app. As soon as you autneticate for a legitimate reason the virus can escalate itself and write to any file on the system.

[Simon]

Originally posted by Gavin:

Someone suggested you might be asked "application xx wants to access your address book, let it?"
How about:
...
"application xx wants to talk over the network, let it?"

This exists already!

It's not from Apple and it's not entirely free, but it works perfectly and is easy to use.

It's called Little Snitch.

[Gavin]

Originally posted by utidjian:
If the user who receives the virus is the admin user it can write to /Applications without authentication. That means it can affect any of the apps in /Applications.

A virus, by definition, attaches itself to a legitimate application or data file that is opened with a legitimate application. IOW it "infects" a host app or data file. In the example virus it was attached to a legitimate MP3. It won't show up in the dock except as iTunes. iTunes is noticeable... but only as iTunes.

Right, but in this case there would still be a background process doing bad things which could be detected by some kernel extension.
Simon mentioned 'little snitch', I'd bet you could write a kernel ext that tested for all the signs people brought up here.

True. But viruses can be patient. If the user is the admin user it can write to anything under /Applications including things that are likely to ask you to authenticate such as Keychain Access.app and System Preferences.app. As soon as you autneticate for a legitimate reason the virus can escalate itself and write to any file on the system.

So a clever virus could drop a bit of binary code into Mail? Or worse, something that you give your admin password to like System Preferences.

That could be defeated by testing the size of the binary against a check sum. If the real size is bigger than a know size the system doesn't start it.

Could that be done by a kernel extension?

Sounds like an open source project to me.

[utidjian]

Originally posted by Gavin:
Right, but in this case there would still be a background process doing bad things which could be detected by some kernel extension.
Simon mentioned 'little snitch', I'd bet you could write a kernel ext that tested for all the signs people brought up here.

Not neccessarily. If, say, Safari were infected... the virus code could be running inside Safari. How are you going to tell what is and is not a legit Safari process? Safari is allowed to get and put stuff all over the internet that any other browser app can go. IOW the virus activity could look like a legit http conection to a web site.

The problem of writing an extension to 'little snitch' is that it is not open source. Gotta wait till the 'little snitch' people do it. The other problem with writing a kernel ext in general to check for certain things is... what exactly do you write, what do you check, how do you check? This has always been the problem for virus scanners... almost every scanner has to have a definition of what to look for and where AFTER the virus is already in existence. Virus scanning solutions to the virus problem are almost always reactive rather than a pro-active.

So a clever virus could drop a bit of binary code into Mail? Or worse, something that you give your admin password to like System Preferences.

That could be defeated by testing the size of the binary against a check sum. If the real size is bigger than a know size the system doesn't start it.

It would have to be more than just a size check. A virus could be written that infects a binary and the infected binary is still the exact same size as the uninfected binary. md5sums are much more exacting. Two different binaries of the exact same size do not yield the exact same md5sum. md5sum comes with fink.

Could that be done by a kernel extension?

I don't know enough about Mac OS X kernel extensions to comment on it. But I don't see why not.

Sounds like an open source project to me.

In fact there are several OSS projects like this that have been around for quite some time. Tripwire, SELinux, RPM... to name a few, that have some or all of that functionality.

[CharlesS]

Originally posted by utidjian:
It would have to be more than just a size check. A virus could be written that infects a binary and the infected binary is still the exact same size as the uninfected binary. md5sums are much more exacting. Two different binaries of the exact same size do not yield the exact same md5sum. md5sum comes with fink.[/B]

The problem with checksums is that they change whenever an app gets its prebinding updated.

[danengel]

Why so complicated solutions like signing applications ot requiring to authenticate?

Simply let the Finder (or the underlying `open'-call) check whether an executable file looks like that. If it has a wrong extension (like .mp3) or any other suspicious property, refuse to open it.

[ibobunot]

[Geobunny]

I'm not here to offer a suggestion, there have been plenty of those, nor will I comment on any of them (until I've had time to come up with a solution myself anyway!), what I will say though, is something that noone else has.

Why are you all assuming that the malicious code has to be a CFM app? Surely it could be anything with the executable bit set, no? This means it could quite easily be transmitted via any email client or SMTP server (or do they strip permissions?). I'm not at my own machine right now, so don't have the dev stuff installed, but can someone check this for me please: write any old ANSI C/C++ code (to create a file or something), compile it and make sure it has the exec bit set, then try double clicking it in the Finder. Does it run? What about with a funny extension on it? What about after going through various SMTP servers?

[Kristoff]

Originally posted by Developer:

� since acquiring a certificate requires at least a valid e-mail address, it's more unlikely that someone would distribute malicious code signed, because it would make him better traceable.

Ah....someone's never been to mailinator

[utidjian]

Originally posted by Geobunny:
I'm not here to offer a suggestion, there have been plenty of those, nor will I comment on any of them (until I've had time to come up with a solution myself anyway!), what I will say though, is something that noone else has.

Why are you all assuming that the malicious code has to be a CFM app? Surely it could be anything with the executable bit set, no? This means it could quite easily be transmitted via any email client or SMTP server (or do they strip permissions?). I'm not at my own machine right now, so don't have the dev stuff installed, but can someone check this for me please: write any old ANSI C/C++ code (to create a file or something), compile it and make sure it has the exec bit set, then try double clicking it in the Finder. Does it run? What about with a funny extension on it? What about after going through various SMTP servers?

It has been said before, in another thread. http://forums.macnn.com/showthread.p...hreadid=207509

There is also some example code you can compile and name whatever you want at: http://tinyurl.com/2blxv
Attach to an email using whatever mail client you like and send it to yourself. Open it by doubleclicking on the attachment (Mail.app will warn you but if you save first and then open it it will not) and the app will run. The execute bit is apparently preserved in Mail.app. I haven't tried other email clients with Mac OS X. All the Linux email clients I have tried remove the execute bit. All other Unix that I have ever tried remove the execute bit. Mac OS X Mail.app is the only exception I know of. The app doesn't need a funny extension. It will execute without one. I haven't tried it with .doc or .mp3 extensions.

Try it yourself.

[MPMoriarty]

Just so I can get this straight...

This vulnerability hasn't been exploited yet, correct?

Intego has just found a weakness and notified us all about it right?

There is no official trojan for Mac OS X affecting users?

Mike

[Gavin]

Right.

The whole thing is basically a stunt designed to scare people into buying software they don't need.

[Gavin]

Originally posted by utidjian:
Not neccessarily. If, say, Safari were infected... the virus code could be running inside Safari. ....

Actually I was talking about the other type, app disguised as a file. So I think I'm right, it would run a process in the background so it doesn't show in the dock. That process could theoretically be spotted as illegitimate.

The problem of writing an extension to 'little snitch' is that it is not open source.
....

I don't think anyone sad anything about an extension to LS. It was mentioned as an example of a kernel ext that watched for suspicious activity.

The other problem with writing a kernel ext in general to check for certain things is... what exactly do you write, what do you check, how do you check?

I don't think it would be that hard to define a set of 'things a bad app tries to do'. Deleting or modifying files not created by that app would be suspicious. Especially if it's a background process and that's the first thing it does. Is it trying to open a binary file in the applications folder for writing? It could be intercepted before it does anything, or the process could be suspended until you OK it if it's legit.

Five guys who write kernel code could hash this out in an hour.

Detecting something bad done by an infected application would be tougher, but what infected the app in the first place?

A virus could be written that infects a binary and the infected binary is still the exact same size as the uninfected binary.

I think somebody would have to be pretty damn clever to pull that off. Without crippling the app anyway.

Again though we're talking about something that would not propagate very easily. You'd either have to be tricked into running the app-disguised-as-file thing first which would then fiddle with the target app (what's the point if you're already running) or you'd have to install a tainted app yourself. If you're dumb enough to download an infected version of iTunes from evil.com you deserve what you get.

[utidjian]

Originally posted by Gavin:
Actually I was talking about the other type, app disguised as a file. So I think I'm right, it would run a process in the background so it doesn't show in the dock. That process could theoretically be spotted as illegitimate.

Not sure I understand you here... if a process is not visible in the dock how is the average user going to spot it? If it is running as something (or part of something) that is visible in the dock but looks like a legit app how is the average user going to spot it? There are dozens of processes loaded (not really running) at any given moment, these can be seen by running top in the terminal. Do you know what all those processes are? How would the average user spot am illegitimate process in top?

I don't think it would be that hard to define a set of 'things a bad app tries to do'. Deleting or modifying files not created by that app would be suspicious. Especially if it's a background process and that's the first thing it does. Is it trying to open a binary file in the applications folder for writing? It could be intercepted before it does anything, or the process could be suspended until you OK it if it's legit.

Five guys who write kernel code could hash this out in an hour.

Well I think it would be quite a bit more complicated than you propose. Wouldn't it be simpler to just make all files and folders NOT in the users ~/ folder writeable ONLY by the root.admin user? Wouldn't it be simpler to make sure that the average user never runs as the admin user except for doing admin on the system? Then the ONLY apps that can affect things outside of the users ~/ folder are the few and well defined setuid root apps.

If it only takes an hour for five guys to make the system more secure... why hasn't it been done?

Detecting something bad done by an infected application would be tougher, but what infected the app in the first place?

Indeed.

I think somebody would have to be pretty damn clever to pull that off. Without crippling the app anyway.

Well... not a good idea to underestimate the cleverness of a determined and malevolent mind.

Again though we're talking about something that would not propagate very easily. You'd either have to be tricked into running the app-disguised-as-file thing first which would then fiddle with the target app (what's the point if you're already running) or you'd have to install a tainted app yourself. If you're dumb enough to download an infected version of iTunes from evil.com you deserve what you get.

Well try and think about it this way...
Say you are someone who is trying to do something nasty to other peoples computers. How would you go about doing it?

*Look for ways in which you can compromise the system. (very difficult in Mac OS X to do this remotely).

*Look for ways to get a legitimate user of that system to do it for you. (You have to get that user to run something as the admin user to have the maximum effect on that system.)
Many Mac users (not all) run as the admin user ALL the time.
The example "trojan" mp3 file is one way to get people to run your program for you. That "trojan" could then infect ALL the mp3s the user has... does that user share his mp3s?
If the "trojan" is run by the admin user it can infect any app in /Applications. Then it can be run by ALL users of that system. The reason for infecting an application rather than just staying a trojaned mp3 is that it can then affect ALL users of the application on that system. The mp3 could be a very popular one and likely to be shared.

*Look for ways to spread an infection by other apps. Something that is very likely to be shared.
I wonder, if say, something like iCal data can be infected as easily as mp3s seem to be.

How do you know when something you download from Versiontracker or MacUpdate or even Apple is or is not infected?

[Gavin]

Originally posted by utidjian:
Not sure I understand you here... if a process is not visible in the dock how is the average user going to spot it?
...
How would the average user spot am illegitimate process in top?

Not spotted by the user but the magic system security kernel thing we are dreaming up.
It would follow some rules to give each running process a suspicion rating then do something based on that. Ignore it, kill it, pop up a warning message, etc.

Well I think it would be quite a bit more complicated than you propose.

I meant defining the rules for identifying a bad process, not actually making it work.

Wouldn't it be simpler to just make all files and folders NOT in the users ~/ folder writeable ONLY by the root.admin user? Wouldn't it be simpler to make sure that the average user never runs as the admin user except for doing admin on the system? Then the ONLY apps that can affect things outside of the users ~/ folder are the few and well defined setuid root apps.

Good. The finder could request a password like System Prefs for anything you need to do to to /Library or /Applications. Might get a little annoying but you really don't touch that stuff much anyway.

Well... not a good idea to underestimate the cleverness of a determined and malevolent mind.

I'll take that as a complement!

Well try and think about it this way...
Say you are someone who is trying to do something nasty to other peoples computers. How would you go about doing it?

Interesting

...
The reason for infecting an application rather than just staying a trojaned mp3 is that it can then affect ALL users of the application on that system.

OK, I'll buy that. On the other hand the vast majority of macs are single user so you won't get much bang for your virus writing buck. Another reason might be that as code attached to a real app you could use its functions and get access to the cocoa libraries. That might make your virus a lot more powerful with less code. Say your virus was not designed to simply do a lot of damage across the Internet but you were trying some sort of stealth distributed computing thing. Like make all the G5s on campus crunch the data for your term paper by adding secret binary code to iTunes. Every time an infected computer runs iTunes they become a node.

The mp3 could be a very popular one and likely to be shared.
I wonder, if say, something like iCal data can be infected as easily as mp3s seem to be.

I'd guess anything with built in meta data. JPEGs, PNGs, QuickTime movies. As long as the spec is extendable you can add stuff, the real app won't see the extra junk as a problem.

How do you know when something you download from Versiontracker or MacUpdate or even Apple is or is not infected?

True. My linux stuff usually has MD5 sums and PGP signatures available on the website so you can test it for authenticity. It's pretty geeky to use though. And it doesn't really prove that there is no sneaky stuff in the code but at least you can trace it back to the author.

[Developer]

If you read what Network Associates writes about this trojan, then this is scary!

[theolein]

Originally posted by Developer:
If you read what Network Associates writes about this trojan, then this is scary!

I didn't see anything that was new in the NA note. What does bother me though is that Apple has yet to respond to this, and that, to me, is scary. It is scary because one of Apple's main bonuses with OSX has been, up until now, the fact that there were no known viruses/trojans for OSX, and it has been a major plus for the Mac platform. Apple not responding to this, or perhaps just leaving it to AV vendors to solve is an even worse response, in my eyes, than Microsoft would do, where generic vulnerabilities do eventually usually get patched.

[JLL]

Originally posted by theolein:
I didn't see anything that was new in the NA note. What does bother me though is that Apple has yet to respond to this, and that, to me, is scary. It is scary because one of Apple's main bonuses with OSX has been, up until now, the fact that there were no known viruses/trojans for OSX, and it has been a major plus for the Mac platform. Apple not responding to this, or perhaps just leaving it to AV vendors to solve is an even worse response, in my eyes, than Microsoft would do, where generic vulnerabilities do eventually usually get patched.

This problem has existed since 1984. Have you seen many trojans exploiting this "hole"?

[Chuckit]

Originally posted by theolein:
What does bother me though is that Apple has yet to respond to this, and that, to me, is scary. It is scary because one of Apple's main bonuses with OSX has been, up until now, the fact that there were no known viruses/trojans for OSX, and it has been a major plus for the Mac platform. Apple not responding to this, or perhaps just leaving it to AV vendors to solve is an even worse response, in my eyes, than Microsoft would do, where generic vulnerabilities do eventually usually get patched.

This is not really a vulnerability in the OS; it's a vulnerability in the user. Unless you specifically double-click on the file (which is listed as an application everywhere possible), it's not going to do any harm. It's not like a networking exploit or a buffer overflow. This virus doesn't exploit anything in the OS to make it more dangerous, so I really don't see what you expect Apple to patch.

[piracy]

Originally posted by Developer:
If you read what Network Associates writes about this trojan, then this is scary!

Um, how so?

"This MacOS trojan generated quite a lot of fuss for no good reason.

It was always well known that any PowerPC application could have ".mp3" or ".jpg" extension appended to it. If it also had a deceptive icon embedded (that of MP3 or JPEG files) then behaviour and appearance_of such a disguised program would be the same as of this trojan.

The only mildly non-trivial discovery associated with this malware is that_its author_managed to combine a valid MP3 file and a PowerPC application in one file without violating any of the two file formats. That means the trojan is playable within iTunes as MP3 sound file and it can also be launched as a program by Finder. This works under MacOS 9 and OS X.

However, dual personality of a file has little relevance to_the malicious function. If_a user is convinced to double click on an icon representing a file the program_will run regardless of being a simple disguised_application_or dual-format file. Thus, the discovery of dual-format files does not really introduce any new penetration or propagation vector. It can only_obfuscate a little the function of the disguised program, which will appear as a valid sound file and it can be_played_from iTunes.

To achieve this dual personality of the file the PowerPC application (Type 'APPL', Creator = 'vMP3')_is registered in the resource fork as 'cfrg' (code fragment) within the data fork. At the same time this data fork (with an ID3 record at the beginning of the MP3 file that holds the binary code) is a valid MP3 file image."

ALL Mac OS applications (except Cocoa) have ALWAYS been able to have:

- Any icon

- Any name

That is FUNDAMENTAL to this trojan. As NAI (correctly) notes, the fact that you can have actual file data in the data fork of a Carbon application is mildly interesting, but almost completely irrelevant. In fact, NAI's analysis concurs with the correct synopsis of this situation, which is that this is nothing new, does not exploit any critical flaw in the OS, and has one barely interesting property that isn't even relevant to the potential "malicious" properties of such a "trojan". The ONLY reason this caused a stir was because of Intego's extremely irresponsible press release. There were 3 other examples of "application trojans" posted to that same news group thread. Should we all panic about them as well? All a "trojan" is, by definition, is an application that does something that the user doesn't expect or desire. If I make a Carbon application right now that tries to delete some files from your home directory, and give it a false icon and name, boom, that's a "trojan". Since trojans also by definition don't spread or infect anything - they rely on tricking the user - this whole thing is one big, fat non-issue and anyone who thinks otherwise is fooling themselves. An application can, and always has been able to, do ANYTHING. Including delete files. Since an application can also have any icon or any name, there's a chance of fooling a user into opening it. Period. THE FACT THAT THIS CONTAINS MP3 DATA IS NOVEL, BUT IRRELEVANT. And if someone says "well, they user might be confused for a while longer because it really could look like an MP3 when the double click on it": there are other ways of even doing this kind of trickery. The fact that a Carbon application and an MP3 (or GIF, JFIF, or anything) are in the same file is interesting, but totally irrelevant, and doesn't represent some kind of fundamental "flaw".

And to the person who said it's scary that Apple hasn't responded: there's nothing to respond *to*. This has been true, known, and possible since 1984. This general type of attack - tricking the user with a file that doesn't spread, propagate, or infect in any way, but may try to do something malicious itself - has always existed and will always exist on ALL computer platforms. Sure, some may use tricks specific to different OSes to try to get people to open something...but that alone doesn't mean there is a flaw. The ONLY thing Apple could do, short of developing an extremely complex and nightmarish application signing infrastructure, is something like one of the following:

- visually badge all executables with some identifier, similar to the way aliases are universally badged

- have some option for the OS to warn you each time a new executable is opened for the first time

- other similar things

Repeat: This is **NOT** a flaw in Mac OS X. It's giving an application a misleading icon and misleading name; at its core this an application and nothing more. The fact that document data is also in the file is slightly interesting and clever, but totally and utterly irrelevant. Re-read the NAI analysis again; the only scary thing here is that people are still talking about this as if it's a problem. (By the way, even though this isn't a REAL problem, I realize it could be a PR problem. That's a completely different ball of wax.)

Also: notwithstanding anything said above, it's good advice for all computer users, including Mac users, to keep your OS up-to-date, and always run up-to-date antivirus software.

[Developer]

Originally posted by piracy:
Um, how so?

I was being ironic. I found the article somewhat humorous so I suggested it for reading.

[piracy]

Originally posted by Developer:
I was being ironic. I found the article somewhat humorous so I suggested it for reading.

Thank goodness.

Anywhere else, one would recognize sarcasm.

On the MacNN forums, you never know.

(And frankly, I didn't even notice that it was you who had posted it.)

:-)

[theolein]

Originally posted by JLL:
This problem has existed since 1984. Have you seen many trojans exploiting this "hole"?

The concept trojan, offering fill in the blank spaces ease of use, has been around how long? Mmmm, I thought so.

[theolein]

Originally posted by piracy:
Um, how so?

"This MacOS trojan generated quite a lot of fuss for no good reason.

It was always well known that any PowerPC application could have ".mp3" or ".jpg" extension appended to it. If it also had a deceptive icon embedded (that of MP3 or JPEG files) then behaviour and appearance_of such a disguised program would be the same as of this trojan.

The only mildly non-trivial discovery associated with this malware is that_its author_managed to combine a valid MP3 file and a PowerPC application in one file without violating any of the two file formats. That means the trojan is playable within iTunes as MP3 sound file and it can also be launched as a program by Finder. This works under MacOS 9 and OS X.

However, dual personality of a file has little relevance to_the malicious function. If_a user is convinced to double click on an icon representing a file the program_will run regardless of being a simple disguised_application_or dual-format file. Thus, the discovery of dual-format files does not really introduce any new penetration or propagation vector. It can only_obfuscate a little the function of the disguised program, which will appear as a valid sound file and it can be_played_from iTunes.

To achieve this dual personality of the file the PowerPC application (Type 'APPL', Creator = 'vMP3')_is registered in the resource fork as 'cfrg' (code fragment) within the data fork. At the same time this data fork (with an ID3 record at the beginning of the MP3 file that holds the binary code) is a valid MP3 file image."

ALL Mac OS applications (except Cocoa) have ALWAYS been able to have:

- Any icon

- Any name

That is FUNDAMENTAL to this trojan. As NAI (correctly) notes, the fact that you can have actual file data in the data fork of a Carbon application is mildly interesting, but almost completely irrelevant. In fact, NAI's analysis concurs with the correct synopsis of this situation, which is that this is nothing new, does not exploit any critical flaw in the OS, and has one barely interesting property that isn't even relevant to the potential "malicious" properties of such a "trojan". The ONLY reason this caused a stir was because of Intego's extremely irresponsible press release. There were 3 other examples of "application trojans" posted to that same news group thread. Should we all panic about them as well? All a "trojan" is, by definition, is an application that does something that the user doesn't expect or desire. If I make a Carbon application right now that tries to delete some files from your home directory, and give it a false icon and name, boom, that's a "trojan". Since trojans also by definition don't spread or infect anything - they rely on tricking the user - this whole thing is one big, fat non-issue and anyone who thinks otherwise is fooling themselves. An application can, and always has been able to, do ANYTHING. Including delete files. Since an application can also have any icon or any name, there's a chance of fooling a user into opening it. Period. THE FACT THAT THIS CONTAINS MP3 DATA IS NOVEL, BUT IRRELEVANT. And if someone says "well, they user might be confused for a while longer because it really could look like an MP3 when the double click on it": there are other ways of even doing this kind of trickery. The fact that a Carbon application and an MP3 (or GIF, JFIF, or anything) are in the same file is interesting, but totally irrelevant, and doesn't represent some kind of fundamental "flaw".

And to the person who said it's scary that Apple hasn't responded: there's nothing to respond *to*. This has been true, known, and possible since 1984. This general type of attack - tricking the user with a file that doesn't spread, propagate, or infect in any way, but may try to do something malicious itself - has always existed and will always exist on ALL computer platforms. Sure, some may use tricks specific to different OSes to try to get people to open something...but that alone doesn't mean there is a flaw. The ONLY thing Apple could do, short of developing an extremely complex and nightmarish application signing infrastructure, is something like one of the following:

- visually badge all executables with some identifier, similar to the way aliases are universally badged

- have some option for the OS to warn you each time a new executable is opened for the first time

- other similar things

Repeat: This is **NOT** a flaw in Mac OS X. It's giving an application a misleading icon and misleading name; at its core this an application and nothing more. The fact that document data is also in the file is slightly interesting and clever, but totally and utterly irrelevant. Re-read the NAI analysis again; the only scary thing here is that people are still talking about this as if it's a problem. (By the way, even though this isn't a REAL problem, I realize it could be a PR problem. That's a completely different ball of wax.)

Also: notwithstanding anything said above, it's good advice for all computer users, including Mac users, to keep your OS up-to-date, and always run up-to-date antivirus software.

Well, in your opinion, it might not be a flaw in Mac OSX, but in my opinion it is, and the fact that an application can masquerade as a document is, in my opinion, not totally and utterly irrelevant.

I am whether you think that's ok or not (and your opinion is your opinion, not mine), still worried about this, and will continue to be so until Apple issues a patch that addresses this problem. As I said in the post above, the first concept trojan has been released by a money hungry AV company (you know, one of those companies whose products you advise us to keep up to date) and the resource forks get preserved apparently by mail if the encoding is done on OSX, which means it doesn't even need stuffing in all cases. Considering that this vulnerability is applicable to any document type (mov, jpg, pdf, txt, rtf etc), it means that even "infected" jpegs can be mailed and there will be any number of users who will double click on that attached video of Paris Hilton...

[piracy]

Originally posted by theolein:
The concept trojan, offering fill in the blank spaces ease of use, has been around how long? Mmmm, I thought so.

Um, no. You are completely wrong. And that is not my opinion, it is fact. It does not offer "fill in the blank spaces ease of use".

It is a BINARY APPLICATION. Someone can't just take it and easily "adapt" this example for malicious use.

But that's not even the point.

It's been possible to make an application appear as a document in this fashion for over two decades. OTHER "TROJANS" HAVE EXPLOITED THIS BEFORE, AS MUCH AS 18 YEARS AGO! There were malicious applications (and later AppleScripts on CDs) that floated around on shareware floppies before the internet as we know it even existed! There were "applications" masquerading as other things on the earliest Mac BBSes. IT'S AN APPLICATION! What about this do you not understand?

This very thing - tricking the user to open something they shouldn't - has been around for over twenty years on the Mac platform. An application being able to contain document data has also been around for that same period of time. An application being able to contain document data in this specific fashion has been around since Mac OS X Public Beta 1H39. The ability of dual-fork files to exist, and for the data fork to contain arbitrary data, is INTRINSIC to the OS. An application can DO ANYTHING; they key is whether or not you "trust" it.

[piracy]

Originally posted by theolein:
Well, in your opinion, it might not be a flaw in Mac OSX, but in my opinion it is, and the fact that an application can masquerade as a document is, in my opinion, not totally and utterly irrelevant.

I am whether you think that's ok or not (and your opinion is your opinion, not mine), still worried about this, and will continue to be so until Apple issues a patch that addresses this problem. As I said in the post above, the first concept trojan has been released by a money hungry AV company (you know, one of those companies whose products you advise us to keep up to date) and the resource forks get preserved apparently by mail if the encoding is done on OSX, which means it doesn't even need stuffing in all cases. Considering that this vulnerability is applicable to any document type (mov, jpg, pdf, txt, rtf etc), it means that even "infected" jpegs can be mailed and there will be any number of users who will double click on that attached video of Paris Hilton...

You are wrong. It is NOT a "flaw" in Mac OS X. The ONLY "trick" the trojan uses is that in icon view, and icon view only, an application can be made to appear indistingushable from a document. There are two visual elements in icon view: the icon, and the name. Either of these have been able to be anything since 1984. Also, let's clear up some further misconceptions you have:

- Intego "released" the proof of concept - WRONG. The proof of concept was posted to a USENET group, comp.sys.mac.programmer.misc, during a discussion of this topic by a programmer. This did not come from Intego. Some Mac user got freaked out, emailed all the AV vendors, and while Symantec and NAI responsibly reviewed it, as they should, Intego decided to use scare tactics to try to capitalize off of it. This is not an Apple issue, this is an AV vendor issue. You seem to have the idea from the tone of your post that it is somehow Apple's responsibility to keep Mac OS X's repuation as worm/virus/trojan free. That is such a wrongheaded view, and not possible. All Apple can do is use good OS design practices to make things like the mass propagation of malware not practical, which they have already done. Mac OS X can have viruses. Mac OS X can have spyware. Mac OS X can have worms. Mac OS X can have trojans. It is not invulnerable, and your apparent attitude that you don't need antivirus software and that this is a "flaw" that Apple should fix is the exact kind of ignorance that will end up biting Mac users hard when there is a REAL issue. That said, because of Intego's handling of this situation, I would not patronize them at all. Patronize a vendor that has proven themselves to be responsible in this realm, such as NAI or Symantec.

- The "proof of concept" offers drop-in ease of use, and can be easily adapted to do something malicious - WRONG. The "proof of concept" is a binary application, and nothing can be "dropped" into it any other binary application. It would be easier to start from scratch (which would be about a 5 minute operation).

- This is completely new, and has never been exploited before, therefore we should worry about it like the sky is falling - WRONG. This type a "trojan" has existed in dozens of different forms over the years on the Mac platform. It takes the blink of an eye to make an application that does something malicious, give it a Word icon, and name it "Important.doc". Why have you never seen or heard of one, you might ask? Because they don't spread! They don't "infect" anything! The propagation is completely manual, and because people get wise to the fact that something is not right and the things die on their own! There have been *three more* "trojans" using the same issue - posted as proof that it's super easy to do - posted as examples to the same newsgroup thread. Should we be all up in arms and worry about those too? The only reason you heard about this one is because of Intego, which susequently caused the mainstream press to pick up an irresistible story: "FIRST TROJAN ATTACKS MAC OS X" (Um, huh? There was no "attack". An attack implies something malicious; this was an application that displayed a dialog box as an example. And "first"? Nope. First that you heard about, yes. But not the first.) "MAC OS X HAS SAME PROBLEMS AS WINDOWS" (Huh? So a freaking application that doesn't spread, infect, or do anything using the oldest trick in the book of tricking the user suddenly brings Mac OS X to the level of a platform with tens of thousands of automated-spread virii and malware, as well as numerous new, administrator-level completely automated remote exploits every month? Um, yeah, ok.)

- This is the first trojan for Mac OS X - WRONG. This is the first time an antivirus vendor went completely nuts about it, and made everyone think that they should panic and that there was some huge, new fatal flaw being exploited.

The ONLY thing that might cause more people to try to make - and publicize - Mac OS X trojans using this technique is all the retarded publicity this got, due to Intego's wildly irresponsible INITIAL press release. If they would have had written a normal advisory, like:

http://vil.nai.com/vil/content/v_101173.htm

or

http://securityresponse.symantec.com...p3concept.html

...then we wouldn't be having this conversation right now.

This is NOT new, NOT a "do it yourself kit" to make new trojans, and NOT anything that hasn't been widely known by any developer since January 24, 1984.

All that said, yes, because of Intego's success using scare tactics instead of doing a normal threat analysis, Apple will probably have to do something in response. However, the ONLY thing they can do is visually badge executables, by perhaps putting a diamond or some other symbol in perhaps the same spot the alias arrow goes. Even if they did that, an application would STILL be able to have:

- any icon

- any name

Even if the icon had a little badge that informed the user it was executable, people will STILL potentially open it.

Even if a dialog box popped up saying "this is an application, but looks like a document, do you still want to continue?" people will STILL potentially open it.

You will ALWAYS be able to trick the user. Always.

I just want to make sure you understand that the only thing Apple can do is try to identify things that are applications; they can't fundamentally prevent someone from giving a non-Cocoa application any icon and any name - including misleading ones. They also cannot prevent a programmer from deciding they want to make document data and application data part of the same file. That's like saying Apple should try to prevent applications from doing something bad, like deleting files. What if an application's PURPOSE is deleting files (like a secure eraser)? It all comes back to the fact that an application can do ANYTHING, and it is fundamentally up to the user to trust it.

The other thing is that modern malware needs to have AUTOMATED, not manual, propagation. It's all well and good that this can be emailed to someone with Mail.app, but that propagation vector isn't even considered valid by security companies: it's completely manual!

I hope I have made it clear that the one and only thing Apple could do to help this is visually identify applications, but equally clear that this very "exploit" (if you can even call it that) has been possible - and HAS been "exploited" - for over twenty years.

Why do you think they call these things a "trojan horse"? The horse didn't break down the gates of Troy, and the gates didn't open on their own...

[CharlesS]

The problem is that with the .app extension, you can force it to always show if the app would otherwise appear to have some different extension, and thus make it impossible to make an app look like an MP3 or something else. Apple should have forced all Carbon apps to have the .app suffix - the 'APPL' type code could have been used for Classic apps only. Of course, if Apple changed things to require the extension now, they'd break MS Word as well as a slew of other important apps.

I guess the way to fix it would be to either:

1. Make suffixes like MP3 which are handled by some app override the 'APPL' type code.

2. Warn the user when an .MP3, a .JPG, or something similar has an 'APPL' type code - something along the lines of "Warning: The file 'trojan.mp3' contains executable code, which may be used to install a virus on your system. Are you sure you want to launch it?" with the "Cancel" button as the default.

[Developer]

Originally posted by CharlesS:
I guess the way to fix it would be to either:

1. [...]
2. [...]

That would fix this special case of a trojan, but not the general case of a trojan, i. e. an application that contains malicious code but pretends to be something useful.

[piracy]

Originally posted by CharlesS:
The problem is that with the .app extension, you can force it to always show if the app would otherwise appear to have some different extension, and thus make it impossible to make an app look like an MP3 or something else. Apple should have forced all Carbon apps to have the .app suffix - the 'APPL' type code could have been used for Classic apps only. Of course, if Apple changed things to require the extension now, they'd break MS Word as well as a slew of other important apps.

Charles, you're smart enough to know that this would have been a bad idea. Requiring that applications end in .app as a part of the Carbon specification might have been possible, but it wouldn't have worked for Classic. A LOT of stuff would have been broken, and even though adding .app to fix it seems easy for us, it would have broken a lot of things. Sure, they could have built some kind of facility for it ("This application looks like a Classic application. Mac OS X requires that all applications end in ".app". Would you like to add it now, and continue opening this application?"), but it would have been impractical and confusing for software that spawned other applications, updaters, special cases which *require* the name to stay the same, and thousands of legacy applications.

I guess the way to fix it would be to either:

1. Make suffixes like MP3 which are handled by some app override the 'APPL' type code.

Ok, so you handle the case of suffixes. What about the case of no suffix? Adding or requiring .app on all applications isn't practical, and sometimes wouldn't even be possible without breaking something, so what about the case of "Hey Ya - Outkast MP3", with no extension, and an MP3 icon? You'll always be able to trick the user. Granted, the goal should be to make it HARDER to trick the user, but it will always be possible. Tricking the user is NEVER completely preventable. These files, by the way, show up clearly as applications in EVERY Finder view *except* icon view. (I will acknowledge that icon view is a common view, and that the Desktop is a common place where downloaded files would end up, and would also display files in icon view.)

2. Warn the user when an .MP3, a .JPG, or something similar has an 'APPL' type code - something along the lines of "Warning: The file 'trojan.mp3' contains executable code, which may be used to install a virus on your system. Are you sure you want to launch it?" with the "Cancel" button as the default.

Ok...and I also offered this as a suggestion in my previous message. But it won't work the way you describe it. This would reasonably have to apply to ALL extensions. So the only choice is to ask the user about EVERY application that doesn't end in .app. Of course, applications that end in .app can also be malicious! There's really no way out when you try to solve what is inherently a social engineering problem by technological means. The only reasonable solution would be to visually badge all executables with an overlay, similar to how aliases are identified. Sure, the metadata/file extension dichotomy helps to trick users, but the idea of getting someone to open something they shouldn't is as old as computers themselves, and can never be fully prevented. I am not saying that nothing should be done, or perhaps this issue shouldn't be revisited, but I want to make it clear that this is NOT new, and nothing now makes it "easier" to "exploit" this.

For just a tip of the iceberg of the challenges faced in seamlessly integrating these environments, look at Fred Sanchez's USENIX 2000 paper on the topic:

http://www.wsanchez.net/papers/USENIX_2000/

[piracy]

Originally posted by Developer:
That would fix this special case of a trojan, but not the general case of a trojan, i. e. an application that contains malicious code but pretends to be something useful.

Indeed. You hit the nail on the head, and I don't understand why people can't see this.

We should always strive for greater security, but you cannot solve social engineering problems with patches and OS updates. There is no "fix" for tricking the user. This is not a virus that exploits a hole or fundamental security flaw. This is not a remote exploit. This is not a worm. It's an APPLICATION.

For the record, I do think a visual badge that something is executable is probably the most practical "solution" here. When an application is sitting on your desktop, a good argument can be made that it shouldn't be able to look indistinguishable from a document in icon and name; however, I don't understand why people think this is something new, or something that hasn't been done before. The only new element here was Intego's FUD, irresponsibility, and idiocy.

[Developer]

Originally posted by piracy:
The only reasonable solution would be to visually badge all executables with an overlay, similar to how aliases are identified.

It's impossible to determine which applications contain malicious code and which not, but if applications were signed, users would have the chance to only launch applications from vendors they trust.
I think that would be a reasonable solution that deals with all kind of trojans.

[CharlesS]

Originally posted by piracy:
Charles, you're smart enough to know that this would have been a bad idea. Requiring that applications end in .app as a part of the Carbon specification might have been possible, but it wouldn't have worked for Classic. A LOT of stuff would have been broken, and even though adding .app to fix it seems easy for us, it would have broken a lot of things. Sure, they could have built some kind of facility for it ("This application looks like a Classic application. Mac OS X requires that all applications end in ".app". Would you like to add it now, and continue opening this application?"), but it would have been impractical and confusing for software that spawned other applications, updaters, special cases which *require* the name to stay the same, and thousands of legacy applications.

Huh? I specifically said, "The 'APPL' type code could have been used for Classic apps only." Of course I understand that Classic apps need to work that way. But for a Carbon app to run natively, I think it would have been better if it had required the .app extension, to make it more obvious.

If I double-clicked an MP3, and all of a sudden the Classic environment started up, that would give me a pretty decent warning that this wasn't an ordinary MP3, and it would give me time to kill the Classic environment before it could run. Of course, this wouldn't help if Classic was already running, but given that many OS X users don't use Classic, such a trojan might not be worth a malware-writer's time, at least not to the same extent as a Carbon app would be.

Ok, so you handle the case of suffixes. What about the case of no suffix? Adding or requiring .app on all applications isn't practical, and sometimes wouldn't even be possible without breaking something, so what about the case of "Hey Ya - Outkast MP3", with no extension, and an MP3 icon? You'll always be able to trick the user. Granted, the goal should be to make it HARDER to trick the user, but it will always be possible.

<snip>

Well, like you say, the goal should be to make it harder to trick the user. Did I ever say that we could make it completely impossible to trick them? I hope not. If I did, my apologies. However, here are a few things to think about:

1. Most users are generally much more cautious about running applications than other types of files.

2. An application with no suffix looks exactly the same as an application with an .app suffix, in the Finder.

3. A file like a JPG or an MP3 will generally be launched with less hesitance than another file, since these files typically don't contain executable code and thus can't be harmful.

4. Users can't be expected to Get Info on every file they download to the Desktop to make sure it's not an application. It's just not realistic, or reasonable.

5. With this technique, you could hide malicious code in many types of files, even a simple .txt file, thus greatly increasing the amount of security necessary on the part of the user. And don't tell me you check every .txt file you ever open to make sure it's not a virus!

6. When the file can go on to be opened in the application you expected it to, after running its code, the user might not even be aware that any code was run in the first place. Completely stealth.

7. I think it's pretty safe to say that any application disguised as an MP3 or something else has a pretty good chance of being malicious.

8. If .app were required for all Carbon apps, and if it would always be shown in the presence of another extension, it would be much harder to disguise an app as an MP3.

[JLL]

Originally posted by CharlesS:
Huh? I specifically said, "The 'APPL' type code could have been used for Classic apps only." Of course I understand that Classic apps need to work that way. But for a Carbon app to run natively, I think it would have been better if it had required the .app extension, to make it more obvious.

If I double-clicked an MP3, and all of a sudden the Classic environment started up, that would give me a pretty decent warning that this wasn't an ordinary MP3, and it would give me time to kill the Classic environment before it could run. Of course, this wouldn't help if Classic was already running, but given that many OS X users don't use Classic, such a trojan might not be worth a malware-writer's time, at least not to the same extent as a Carbon app would be.


Well, like you say, the goal should be to make it harder to trick the user. Did I ever say that we could make it completely impossible to trick them? I hope not. If I did, my apologies. However, here are a few things to think about:

1. Most users are generally much more cautious about running applications than other types of files.

2. An application with no suffix looks exactly the same as an application with an .app suffix, in the Finder.

3. A file like a JPG or an MP3 will generally be launched with less hesitance than another file, since these files typically don't contain executable code and thus can't be harmful.

4. Users can't be expected to Get Info on every file they download to the Desktop to make sure it's not an application. It's just not realistic, or reasonable.

5. With this technique, you could hide malicious code in many types of files, even a simple .txt file, thus greatly increasing the amount of security necessary on the part of the user. And don't tell me you check every .txt file you ever open to make sure it's not a virus!

6. When the file can go on to be opened in the application you expected it to, after running its code, the user might not even be aware that any code was run in the first place. Completely stealth.

7. I think it's pretty safe to say that any application disguised as an MP3 or something else has a pretty good chance of being malicious.

8. If .app were required for all Carbon apps, and if it would always be shown in the presence of another extension, it would be much harder to disguise an app as an MP3.

We live in a world where people open attachments in English written mails supposedly from their non English speaking aunt.

Users don't notice the extension - they just open the attachment, and if a dialog warning the user that it might contain malicious code shows up, they will just click Continue anyway..

[CharlesS]

Originally posted by JLL:
We live in a world where people open attachments in English written mails supposedly from their non English speaking aunt.

Users don't notice the extension - they just open the attachment, and if a dialog warning the user that it might contain malicious code shows up, they will just click Continue anyway..

Well, such people can't be helped. But wouldn't you like to be warned if that MP3 you're double-clicking on isn't really an MP3? I know I would. I also know that I wouldn't just click Continue, so there's at least one user intelligent enough to read the damn dialog box.

Don't tell me there's no chance you could ever open a .txt file without giving it a second thought. What a pain in the ass it would be to have to check every one of these before opening it!

Seriously. I guess we should get rid of the "Are you sure?" box when reformatting your hard drive, too. Because users just click "Continue" anyway...

Come on, surely you can come up with a better argument than that.

[piracy]

Originally posted by CharlesS:
Well, such people can't be helped. But wouldn't you like to be warned if that MP3 you're double-clicking on isn't really an MP3? I know I would. I also know that I wouldn't just click Continue, so there's at least one user intelligent enough to read the damn dialog box.

Don't tell me there's no chance you could ever open a .txt file without giving it a second thought. What a pain in the ass it would be to have to check every one of these before opening it!

Seriously. I guess we should get rid of the "Are you sure?" box when reformatting your hard drive, too. Because users just click "Continue" anyway...

Come on, surely you can come up with a better argument than that.

I don't think anyone's arguing that Apple shouldn't try to provide some feedback in this situation. Whether it's a visual badge, a dialog box, etc., and how it's implemented is immaterial. My problem is people thinking this is something new, or that this is some kind of "do-it-yourself trojan kit" that can be easily adapted to drop in malicious code. That is false. There is nothing new about this, fundamentally, and this doesn't exploit a "flaw" in Mac OS X. Even though there have been dozens of "trojans" like this over the years in various forms on Mac OS - applications that masquerade as something else - because of all the PR this one got, exclusively because of Intego's irresponsible, self-serving press release, it's become like one of those gag snakes that you can't put back into the can. Because of all the publicity, and the chance for copycat attempts using this technique BECAUSE OF the publicity (NOT because this is "new"), I do agree that if there is an easy way for Apple to address this, it should. By the way, since the vast, vast, vast majority of applications that would spawn the type of dialog you describe are legitimate, that is a very bad idea. A better idea would be, as I said, to visually identify, right in the icon, any application as executable - just like aliases. There's no reason to harass the user for every single file of type APPL. And if you advocate a dialog only for files of type APPL with extensions, well, that's a better idea - but then you don't catch the case of malicious files WITHOUT extensions. Perhaps a combination of the two ideas is in order:

- a non-intrusive but easily recognizable visual badge on EVERY file that is executable (Classic, Cocoa, or Carbon)

- some kind of optional dialog warning when a file with any extension OTHER than .app has type APPL and is opened

[CharlesS]

Originally posted by piracy:
By the way, since the vast, vast, vast majority of applications that would spawn the type of dialog you describe are legitimate, that is a very bad idea.

Originally posted by CharlesS:
I guess the way to fix it would be to either:

1. Make suffixes like MP3 which are handled by some app override the 'APPL' type code.

2. Warn the user when an .MP3, a .JPG, or something similar has an 'APPL' type code - something along the lines of "Warning: The file 'trojan.mp3' contains executable code, which may be used to install a virus on your system. Are you sure you want to launch it?" with the "Cancel" button as the default.

The vast, vast, vast majority of files with a document extension (.MP3, .JPG, .TXT, etc.) and an 'APPL' type code are legitimate? I defy you to name one legitimate application with such an extension.

Have you actually read my posts?

[Developer]

Originally posted by CharlesS:
The vast, vast, vast majority of files with a document extension (.MP3, .JPG, .TXT, etc.) and an 'APPL' type code are legitimate? I defy you to name one legitimate application with such an extension.

If such applications would be marked as suspicious by the OS, and I were to write such a trojan, I would just do without the extension then. Most have extensions hidden, so they wouldn't see any difference. End even those who have not extension hidden, I would bet that most wouldn't notice either.

And if all applications get an ugly badge or annoying dialog, I would call my trojan "Funny Presentation.app" and 70% would launch it. If I then really have some lame presentation in addition to malicious code nobody will notice and the thing will be mailed through the offices.

The problem with trojans can only be solved by signing applications.

[piracy]

Originally posted by CharlesS:
The vast, vast, vast majority of files with a document extension (.MP3, .JPG, .TXT, etc.) and an 'APPL' type code are legitimate? I defy you to name one legitimate application with such an extension.

Have you actually read my posts?

Yes, but you can't reasonably ignore files without extensions. What about the case of malicious applications with no file extension, but an MP3 icon?

[CharlesS]

Originally posted by piracy:
Yes, but you can't reasonably ignore files without extensions. What about the case of malicious applications with no file extension, but an MP3 icon?

When I see something with no extension, I assume it could be an app. After all, the usual .app extension is also hidden, so something without an extension looks like an app. A file with an MP3 icon and no extension automatically looks suspect. There are other problems as well, such as the fact that if you try to drag the file over iTunes' icon, it won't highlight, since it's actually an app. It's true that this could fool some users thanks to the extension-hiding feature. It is because of this that I have never liked that feature much at all. Originally, it was pretty hard to get files into your computer from over the network that preserved the hidden bit, though. The fact that Panther's .zip archives preserve this is disturbing - if it behaved properly and didn't preserve this bit, it would be difficult to transfer a file to someone and have the extension hidden on his/her end. Therefore, if something didn't have an extension, it would immediately set off warning bells (although it still should anyway).

However, when I see a file with an explicit .mp3 suffix, I expect that file to be an MP3 file. Prior to the discovery that code can be put into the ID3 section in this way, there was no real cause for a reasonable person to worry about double-clicking an MP3 file - it was safe. Now, you don't know. Because even if the MP3 file didn't have code at some point, how do you know that it hasn't been added since? I see the potential for a nasty virus that would infect MP3 files by sticking code in their ID3 sections and set up the appropriate resources in the resource fork. This virus could also infect .txt files, .plist files, .html files - anything in which you could add arbitrary data without compromising the format. All of a sudden, none of your files are safe. Want to read the Read Me file for an icon collection you downloaded? Better scan it first. Want to play an MP3 file that's been sitting in your iTunes library for 6 months? Better scan it. Manage to catch a virus? Better scan and disinfect not only your hard disk, but all your data backups as well. And you'd better also alert everyone you've ever sent as much as a text file to. You see? This is a problem that needs to be fixed. Any file with some other extension and an 'APPL' type code needs to either throw up a dialog box or just ignore the type code and open with whatever it would have opened with otherwise. Period.

If the fix comes out soon enough and everyone gets it, it can stave off this virus from being written by making it not worth the author's time. However, complacency will not get us anywhere.

[piracy]

Originally posted by CharlesS:
<snip>

Ok, then, a couple questions:

1. How is this different than anything that could have been done for the last four years since Public Beta?

2. If this is so urgent now, why shouldn't it have been "fixed" before? Is this predicated on the fact that there's publicity about it now?

Also, while I fundamentally agree that it's theoretically possible for a virus - as opposed to just a trojan - to exploit this, what's its propagation vector? How does it spread from machine to machine? Do you envision some intereresting/tempting file that is forwarded around via email among friends, slowly infecting files and perhaps activating its payload at some future point? I agree this is possible, but it's always been possible. Nothing has changed.

Once again, I do agree that the case applications with inappropriate extensions should be handled somehow; I'm just curious why you think this is an issue all of a sudden.

[CharlesS]

Originally posted by piracy:
Ok, then, a couple questions:

1. How is this different than anything that could have been done for the last four years since Public Beta?

I'm sure it could have been done before. But to the best of my knowledge, it had not yet been discovered that executable code could be hidden in the ID3 section of an MP3 file and execute.

Let's look at it this way. Suppose a bug shows up in Windows XP that allows some hacker to compromise your system. Well, this bug has probably been there since the launch of XP, so it's not new. But, I don't think anyone would disagree that it needs to be fixed pronto once it's found.

2. If this is so urgent now, why shouldn't it have been "fixed" before? Is this predicated on the fact that there's publicity about it now?

If we had known that code could be hidden in an ID3 tag before, then yes, it should have been fixed. I wasn't aware of this, but then I don't program with CFM. If it was common knowledge, then yes, it should have been fixed long ago. Since it wasn't fixed, this is irrelevant to the discussion - now it certainly is well known, and it damn well needs to get fixed soon.

Also, while I fundamentally agree that it's theoretically possible for a virus - as opposed to just a trojan - to exploit this, what's its propagation vector? How does it spread from machine to machine? Do you envision some intereresting/tempting file that is forwarded around via email among friends, slowly infecting files and perhaps activating its payload at some future point? I agree this is possible, but it's always been possible. Nothing has changed.

They can be transmitted via the usual methods: e-mail, removable media, burnt CD's, etc. The difference is that usually, viruses could only infect applications - data files in non-MS formats were usually immune. Now, it appears that just about any file on your disk could be infected with a virus. I consider that to be a new development in which something has changed. And given the hype, someone could easily write this virus soon, if the hole isn't patched.

[theolein]

This needs to be repeated:

Originally posted by CharlesS:
...
However, when I see a file with an explicit .mp3 suffix, I expect that file to be an MP3 file. Prior to the discovery that code can be put into the ID3 section in this way, there was no real cause for a reasonable person to worry about double-clicking an MP3 file - it was safe. Now, you don't know. Because even if the MP3 file didn't have code at some point, how do you know that it hasn't been added since? I see the potential for a nasty virus that would infect MP3 files by sticking code in their ID3 sections and set up the appropriate resources in the resource fork. This virus could also infect .txt files, .plist files, .html files - anything in which you could add arbitrary data without compromising the format. All of a sudden, none of your files are safe. Want to read the Read Me file for an icon collection you downloaded? Better scan it first. Want to play an MP3 file that's been sitting in your iTunes library for 6 months? Better scan it. Manage to catch a virus? Better scan and disinfect not only your hard disk, but all your data backups as well. And you'd better also alert everyone you've ever sent as much as a text file to. You see? This is a problem that needs to be fixed. Any file with some other extension and an 'APPL' type code needs to either throw up a dialog box or just ignore the type code and open with whatever it would have opened with otherwise. Period.

If the fix comes out soon enough and everyone gets it, it can stave off this virus from being written by making it not worth the author's time. However, complacency will not get us anywhere.

Whether it's new or not is not the issue. The fact that it makes double clicking any document type file dangerous is what makes it a bug in the OS, IMO, easy propogation or not. It is a risk that Windows, amazingly, doesn't have. Piracy states that the Mac OSX platform's reputation being at stake is of no consequence, but that is one of the many reasons why I use OSX, and I'm pretty sure that it is a major factor in adoption of the Apple platform. The nightmare of AV vendors software on Windows is one of the things that drives me crazy about Windows (Product activation, failure to catch new threats, Product subscriptions etc etc). The fact that I haven't had to have AV software on my Mac has been a major plus. Linux is safer than OSX in this respect in that it doesn't have resource fork support, and not many people on Linux use AV software, because they don't have to, in general.