[Macola]

http://www.intego.com/news/pr40.html

Technically, it's a Trojan horse, not a virus, but is this legitimate? I haven't seen any info elsewhere.

[danengel]

I think someone at Apple is already preparing a fix which will be included in the next Security Update, and in the next major release, all similar holes will be eradicated from OS X.

[piracy]

So what?

Mac OS X can have trojans. Mac OS X can have viruses. Mac OS X can have security issues.

It's just a lot harder to exploit all of these things on Mac OS X for logistical, technical, and statistical reasons.

It is a real concept. There is an example in this thread.

However, it seems that this may be at best questionable, as the "proof of concept" is nothing more than a standalone application that has been given a creator type of 'APPL', but with the file extension '.mp3', and the contents of an mp3. While the file does indeed appear at first glance to be an ordinary mp3, what can admittedly be potentially dangerous, it is in fact an application.

Additionally, as has been pointed out by others elsewhere and below, the file needs to be transported in such a way as to keep the resource fork intact.

[stephenh]

You also have to find some way to keep the resource fork intact. Otherwise it won't work.

[osiris]

IMO this threat is a BOGUS bunch of doo dooky dinky poo


thankfully

[Millennium]

Something doesn't smell right about this. I'm not sure I understand how a valid MP3 file can be executed as an app, even if it attempts to masquerade as one. If the OS were to launch it as an app, then the app should crash immediately.

However, it's possible that the article is worded poorly. It was certainly awkward at a couple of points. For now, therefore, it would be wise to treat this as a real threat until proven otherwise. Better safe than sorry.

On another note, the only real way to close this hole (which boils down to user error) is a two-step process:

1) Remove the option to hide filename extensions, and stop hiding the .app on app packages.

Frankly, I would welcome such a move. This is a large part of how users can be fooled into running trojans on Windows, and the paradigm has infected the Mac as of OSX. I would love to see Apple remove this cancer of a misfeature.

2) Display some kind of icon badge over the icons of all valid applications.

This is harder, because the OS would need to check filename extension, package format (if it applies), and resource fork (if any) of each and every file to determine whether it should badge the file. This could lead to slowdowns in the Finder, particularly when displaying many files at once. However, it would become impossible to disguise an app as anything else, unless the icon were to somehow be completely hidden.

[piracy]

Originally posted by Millennium:
Something doesn't smell right about this. I'm not sure I understand how a valid MP3 file can be executed as an app, even if it attempts to masquerade as one. If the OS were to launch it as an app, then the app should crash immediately.

However, it's possible that the article is worded poorly. It was certainly awkward at a couple of points. For now, therefore, it would be wise to treat this as a real threat until proven otherwise. Better safe than sorry.

On another note, the only real way to close this hole (which boils down to user error) is a two-step process:

1) Remove the option to hide filename extensions, and stop hiding the .app on app packages.

Frankly, I would welcome such a move. This is a large part of how users can be fooled into running trojans on Windows, and the paradigm has infected the Mac as of OSX. I would love to see Apple remove this cancer of a misfeature.

2) Display some kind of icon badge over the icons of all valid applications.

This is harder, because the OS would need to check filename extension, package format (if it applies), and resource fork (if any) of each and every file to determine whether it should badge the file. This could lead to slowdowns in the Finder, particularly when displaying many files at once. However, it would become impossible to disguise an app as anything else, unless the icon were to somehow be completely hidden.

Millennium, none of what you said would help this situation. This is basically a little Classic/Carbon oversight catching up with us.

The file extension is NOT hidden: the full name of the file is "filename.mp3". The Mac OS X Finder uses the file extension information to judge how it is displayed to the user, i.e., with the standard mp3 icon, appearing as a normal mp3 file. However, the CFM metadata speaks differently: the file has a type of APPL, identifying it as an application. The launch behavior (i.e., what happens when it's double clicked) trumps the display behavior (i.e,, a normal mp3). This is essentially nothing more than a CFM application with an mp3 extension and Finder icon. (It's actually a little more...it can be a valid mp3, but with a PowerPC code fragment embedded in the ID3 section - which is executed by the OS).

A minor update in how the OS displays and handles these special-case items - items with APPL types, but inappropriate extensions such as mp3, jpg, etc - can easily solve this predicament.

[Millennium]

Originally posted by piracy:
Millennium, none of what you said would help this situation. This is basically a little Classic/Carbon oversight catching up with us.

It doesn't close the current hole, I will admit. But this is a symptom of a larger hole (a "meta-hole", if you will): the fact that users do not have a reliable way of telling an application from any other kind of file. There needs to be a completely foolproof way of doing so.

The file extension is NOT hidden: the full name of the file is "filename.mp3". The Mac OS X Finder uses the file extension information to judge how it is displayed to the user, i.e., with the standard mp3 icon, appearing as a normal mp3 file. However, the CFM metadata speaks differently: the file has a type of APPL, identifying it as an application. The launch behavior (i.e., what happens when it's double clicked) trumps the display behavior (i.e,, a normal mp3). This is essentially nothing more than a CFM application with an mp3 extension and Finder icon. (It's actually a little more...it can be a valid mp3, but with a PowerPC code fragment embedded in the ID3 section - which is executed by the OS).

The fix does not apply here, no; I suggested it as a matter of looking forward and anticipating future attacks.

A minor update in how the OS displays and handles these special-case items - items with APPL types, but inappropriate extensions such as mp3, jpg, etc - can easily solve this predicament.

It solves this predicament, but it doesn't solve the underlying problem.

[Oneota]

I also don't like how Intego worded their press release. They say that the currently known file is benign (good), then say that it opens the door for future things like erasing user data, emailing itself to other users, etc.

But they're clearly using scare tactics in their press release to get people to buy their product.

Heck, I wouldn't be too surprised if they came up with this virus themselves to convince Mac users that they need virus protection (since I'm sure the Mac market for virus protection is looking pretty dismal these days).

[Millennium]

Originally posted by Oneota:
But they're clearly using scare tactics in their press release to get people to buy their product.

If scare tactics are necessary to get people to practice good security habits, then so be it. I'm glad this finally happened. That it would happen someday is inevitable, and best that it happens while the userbase is still relatively small, such that by the time the userbase grows it might be more security-conscious than the Windows userbase.

I do not condone the writing of viruses, trojans, or other malicious code. I've been hit too many times myself to condone that. But bad though this is, it needed to happen.

[Person Man]

Originally posted by Millennium:
It doesn't close the current hole, I will admit. But this is a symptom of a larger hole (a "meta-hole", if you will): the fact that users do not have a reliable way of telling an application from any other kind of file. There needs to be a completely foolproof way of doing so.

The fix does not apply here, no; I suggested it as a matter of looking forward and anticipating future attacks.

It solves this predicament, but it doesn't solve the underlying problem.

We can check to see if one of your fixes would even be necessary. Create a blank file in the finder. Rename it to test.jpg.app (or test.mp3.app) and see how the operating system displays it (with both hide filename extensions turned on and off). Now create a folder and give it the name test.jpg.app and see how the operating system handles it.

I'm not at my computer to be able to verify this, which is why I'm typing this.

I don't think the operating system always hides the ".app" extension. Certainly not if it's a file. The way ".app" applications work is that the file is actually a folder (a bundle or package) containing several files. OS X hides the ".app" extension in this case, because CFM applications (the whole application self contained in the file) do not need the .app extension.

If I get a chance to test this quickly enough, I'll post the results here.

[Macola]

Originally posted by Oneota:
I also don't like how Intego worded their press release. They say that the currently known file is benign (good), then say that it opens the door for future things like erasing user data, emailing itself to other users, etc.

But they're clearly using scare tactics in their press release to get people to buy their product.

Heck, I wouldn't be too surprised if they came up with this virus themselves to convince Mac users that they need virus protection (since I'm sure the Mac market for virus protection is looking pretty dismal these days).

My thoughts exactly. I've already had a few of my clients contact me and ask if they should buy the Intego antivirus package.

[car1son]

Just for my edification... how would a file with bogus CFM arrive on your system? Doesn't that require a complex structure rather than a flat file, meaning MacBinary or Stuffit or MIME encoding (or physical media)? Aren't those things most network file transport mechanisms (Apple AFP file sharing and Apple Mail excluded) don't carry?

[piracy]

Originally posted by car1son:
Just for my edification... how would a file with bogus CFM arrive on your system? Doesn't that require a complex structure rather than a flat file, meaning MacBinary or Stuffit or MIME encoding (or physical media)? Aren't those things most network file transport mechanisms (Apple AFP file sharing and Apple Mail excluded) don't carry?

Yes. As has been stated above, any type of binary movement/propagation of the file without proper handling (i.e., StuffIt, MacBinary) would render it useless. So while an interesting exercise of this conflict between metadata and file extensions, this "trojan" is really not much of a trojan.

[Person Man]

Originally posted by Person Man:
We can check to see if one of your fixes would even be necessary. Create a blank file in the finder. Rename it to test.jpg.app (or test.mp3.app) and see how the operating system displays it (with both hide filename extensions turned on and off). Now create a folder and give it the name test.jpg.app and see how the operating system handles it.

I'm not at my computer to be able to verify this, which is why I'm typing this.

I don't think the operating system always hides the ".app" extension. Certainly not if it's a file. The way ".app" applications work is that the file is actually a folder (a bundle or package) containing several files. OS X hides the ".app" extension in this case, because CFM applications (the whole application self contained in the file) do not need the .app extension.

If I get a chance to test this quickly enough, I'll post the results here.

Ok, I had a chance to play with my computer.

I took an MP3 file, with the name file.mp3, and renamed it to file.mp3.app

The icon changed to the generic icon, and the file name display read "file.mp3.app" It showed this regardless of whether Hide filename extension was on or off.

Then, with hide filename extensions turned on, I took another file, and renamed it just "File.app" As expected, the extension disappeared. Then I renamed it to file.mp3. The operating system asked me if I really wanted to change the extension from .app to .mp3, I said yes, and the file displayed as "file" (without the extension). Then I changed it to "file.mp3.app" again I was asked if I wanted to change the extension, and I answered yes. The filename as displayed in the finder was "file.mp3.app" Again, this is with hide extensions on.

I turned hide extensions off, and made a folder, and named it "folder.mp3.app" The Finder displayed "folder.mp3.app" I made another folder, and named it folder.app, the .app disappeared (as expected).

So, bottom line, from these tests, it appears impossible to fool a user with only a double extension, because when there is a double extension on a file or folder, the OS will display both extensions, regardless of how the hide filename extensions option is set.

[besson3c]

Originally posted by piracy:
Yes. As has been stated above, any type of binary movement/propagation of the file without proper handling (i.e., StuffIt, MacBinary) would render it useless. So while an interesting exercise of this conflict between metadata and file extensions, this "trojan" is really not much of a trojan.

Exactly, the second it hits anything that isn't a Mac (or Netatalk, or HFS savvy rSync data), this thing is killed... this probably includes email transmission.

In my books, this thing is useless in its current state.

[car1son]

Originally posted by besson3c:
this probably includes email transmission.

It excludes non-Mac eMail. I tried sending it to myself from OS X Mail and retrieved it with Entourage v.X, and it's still an application. However, as expected, uploading it via FTP and downloading it again via FTP defangs it (viewed from Terminal, the pre- and post-FTP files are identical according to diff.).

[Rickster]

What amuses me about this whole thing is that people think it has something to do with OS X's introduction of filename-based typing. It doesn't look like an MP3 because its extension is ".mp3", it looks like an MP3 because its resource fork contains a copy of iTunes' MP3-file icon and defines that icon as its own.

Guess what? This exploit looks and acts the same on Mac OS 9. Anyone could have constructed the same thing five years ago... just with a MacAmp (or SoundApp or Audion or whatever) MP3-file icon. Including the ".mp3" extension would serve the same purpose it does now: it makes the camouflage more convincing to the victim.
(Plenty of MP3 files and other files came with extensions back in those days... they just didn't mean anything to the operating system. This one doesn't either, since OS X favors the HFS filetype over the extension... it's just there for social engineering.) Heck, it could've been done ten years ago by disguising the app as an image file or SimpleText document or something.

If anything's changed to make the world more vulnerable to this issue, it's that there's a greater number of possible credible disguises. It's mostly coincidence that before OS X came along, there were also fewer apps bundled with the OS, and thus fewer common filetypes that always look the same on everybody's machines -- if you were to paste an MP3-file icon on an app to hide its true nature, you'd have maybe a one in three chance of your Trojan looking just like the victim's legitimate MP3 files.

And of course, there's the whole issue of this exploit relying on resource forks and HFS metadata, but others have already covered that pretty well.

I was curious to see how Apple Mail's transparent encoding and decoding of attachments would affect this... I tried emailing it to myself (from one 10.3.3 box to another), and found that on the receiving end it didn't show the fake-MP3 icon. It had a generic app icon instead, though who knows whether that was just a transient bug or a security feature. (Apple Mail does put up a warning about potential viruses and such when you attempt to launch any app from an email attachment, of course.)

So what can Apple do about the vulnerability? Well, it'd be a start to just kill support for single-file-with-rsrc apps, which I wouldn't be surprised to see happen eventually anyway. But that wouldn't really solve things... you can just as easily create a bundled application with a double extension "virus.mp3.app"; the ".app" can be hidden on 10.2 and earlier but will always show on 10.3. (Of course, I'm not sure if Joe User will recognize "foo.mp3.app" as a potential risk even if the title does show.) Maybe a good solution would be to have additional, more urgent "possible virus" warnings for cases in which an executable has conflicting filetype metadata.

I've long thought the best solution for this sort of security issue is to establish application-based access control in addition to user-based privileges. Any random executable you download from the 'Net shouldn't be able to destroy everything in your home directory -- the different processes I run should be allowed different levels of access to my files (and while we're at it, to other running processes as well). Of course, the fun part about implementing that is designing the user experience so that Joe User doesn't get sick of privilege management and give everything unrestricted permissions.

[Mediaman_12]

Originally posted by Person Man:
So, bottom line, from these tests, it appears impossible to fool a user with only a double extension, because when there is a double extension on a file or folder, the OS will display both extensions, regardless of how the hide filename extensions option is set.

You can 'fool' unsuspecting users another way though (but it takes some doing).
If the trojan was created as a 'carbon' app (the type where you can't do a 'show package contents') so it is a single file, you then can call this app anything (even give it a false extension example you could call it 'listen to this.mp3'). This doesn't give it a .mp3 icon though, it would have a default 'app' icon, what you can do though it give this app a 'iTunes mp3' file icon (this would catch a good percentage of Mac users who mostly have iTunes installed).
To most unsuspecting users this would look like a .mp3 file, *only when you click it and it launches instead of opening in iTunes, would most people realise that something 'odd' was happening, but then it is to late.
pic example of Word with this done to it
*If you did a 'get info' it would still have the type 'application', but are people who are going to open an unsolicited mp3 going to do this. It also can only travel directly 'mac to mac' via email, but if it got going it would spread slowly as I bet every mac user has at least one other in there address book.
An excellent (and simple) way to for Apple to stop trojans using the address book to spread is to use a similar system to the keychain. Where anytime a new app asks for access to the address book it pops up a 'keychain like' alert saying "Application ???? wants to open your Address Book. Let it continue" <OK> <Cancel>. Surely nobody would allow 'listen to this.mp3' access to the Address Book!

dam looks like in the time I typed this Rickster beat me to the punch.

[Kristoff]

This whole thing is lame.

What a waste of time to even think about it.

I have had more productive meditation sessions pondering how they get the cream filling inside a Twinkie.


This isn't news. That Slashdot picked the story up is even stranger...especially considering the quantity and quality stories I have submitted that have been rejected.

As Piracy said:
Move along...nothing to see here...

[nsxpower]

Something is sketchy with Intego. They are the only and the first to find/fix this new "Virus" ... really looks like they are trying to seel their product, I say class action lawsuit the bastards.

From what I understand, the virus is just a CFM executable with no hidden extension or anything. Launching it (double clicking) will run it, dragging to iTunes will play the MP3 or give and error, and Mail.app actually identifies it as an executable if you try to open/run it from Mail.app.

As someone already mentioned this is "proof of concept" virus and the whole deal is blown out of proportion by Inego ... see my first point about class action. Hell Nokia just got hit with one ... they fault, stop making crap phones and may be your sales will be better!

Example: http://www.scoop.se/~blgl/virus.mp3.sit <-- Actual VIRUS !!! SO BE CAREFULL !!!

http://groups.google.com/groups?hl=e...nhof.s e#link6

[nsxpower]

Get Info show that the "MP3 File" is actually an application.

[besson3c]

Originally posted by car1son:
It excludes non-Mac eMail. I tried sending it to myself from OS X Mail and retrieved it with Entourage v.X, and it's still an application. However, as expected, uploading it via FTP and downloading it again via FTP defangs it (viewed from Terminal, the pre- and post-FTP files are identical according to diff.).

Were you sending the attachment from Sendmail/Postfix enabled Mac to another Mac through localhost, or were you using your ISP's SMTP server?

[besson3c]

Originally posted by Rickster:
So what can Apple do about the vulnerability? Well, it'd be a start to just kill support for single-file-with-rsrc apps, which I wouldn't be surprised to see happen eventually anyway. But that wouldn't really solve things... you can just as easily create a bundled application with a double extension "virus.mp3.app"; the ".app" can be hidden on 10.2 and earlier but will always show on 10.3. (Of course, I'm not sure if Joe User will recognize "foo.mp3.app" as a potential risk even if the title does show.) Maybe a good solution would be to have additional, more urgent "possible virus" warnings for cases in which an executable has conflicting filetype metadata.

Don't you mean 10.1 and earlier?

[besson3c]

Originally posted by nsxpower:
Example: http://www.scoop.se/~blgl/virus.mp3.sit <-- Actual VIRUS !!! SO BE CAREFULL !!!

Isn't this the URL to the virus example which doesn't actually do any harm, but simply throws up an alert?

[nsxpower]

DP

[nsxpower]

Originally posted by besson3c:
Isn't this the URL to the virus example which doesn't actually do any harm, but simply throws up an alert?

Yes, but who said that it could not be replaced with something malicious (since it's been circulated on forums) + People DON'T double click it, open it in BEEdit and look at the code if you are interested.

PS

It would not be smart to post an actual virus on Mac forums, would it?

[piracy]

A few more thoughts on this:

This "trojan" is one step away from simply writing a malicious application, naming it whatever.mp3, and pasting an mp3 icon onto it.

The only major difference is that the trojan:

- actually contains valid mp3 data, and

- displays the mp3 icon by default

But if the goal is to get someone to double click a file, does it really matter?

The bottom line is that this is purely social engineering. And even so, it's still less effective as a trojan than, say, a Windows trojan or virus, because:

- any binary propagation requires it be encoded (.sit., .bin, etc.); any spread as raw binary will render it useless

- relative to other platforms, no easy way to propagate via email


This general issue - the concept of file/filesystem metadata vs file extensions, and how these are presented to the user, and how the user interacts with them - has been discussed at length since Mac OS X Public Beta. The only different now is that someone made a proof of concept, and Intego decided to capitalize on it, which will likely result in a flurry of (inaccurate) negative press.

This type of fundamental issue - double-clicking on a specific document type, such as an audio or graphic file, without realizing it is a malicious application - could potentially be solved by disallowing application launch of any file with any extension other than .app. However, even this doesn't solve the social engineering problem: the file could still be "advertized" as something else, and actually end up being a malicious application. An application that does something malicious - while even pretending to be helpful or benign - is trivial to write. This is the very definition of a trojan. However, a trojan is actually damaging on a wide scale if it can be widely spread - something that is not possible on Mac OS X without great sophisitcation (compared to the relative ease these same tasks are accomplished on Windows, with things like Internet Explorer, Office, and Outlook).

The bottom line is that this seriously is a non-story, and I'm more surprised that Intego even latched onto it. This will get press as the "FIRST TROJAN FOR MAC OS X", implying that it's something malicious, or in the wild, or spread in the same fashion as Windows, when none of the above will be true.

[alphasubzero949]

Originally posted by nsxpower:


Get Info show that the "MP3 File" is actually an application.

The same information appears in column view. However, those who view Finder windows in the icon mode won't have a clue. Unfortunately I know many novice OS X users who exclusively use icon view.

[theolein]

The bottom line is that Apple has to get a patch out for this (at a minimum making the Finder display files which have "APPL" type file codes in the resource forks as applications). The reason that this is dangerous is that, in theory, this trojan would also work on .jpg extensions for preview and .rtf extensions for text edit. It is by no means a great feat to get people to download stuffed files of these types (for example: "Great huge wallpaper jpeg pic of Anna Kournikova nude! Compressed to make your salivating download time shorter!") and get them to unstuff them and double click them.

I just wrote to Apple about it.

[piracy]

Originally posted by alphasubzero949:
The same information appears in column view. However, those who view Finder windows in the icon mode won't have a clue. Unfortunately I know many novice OS X users who exclusively use icon view.

It doesn't matter. This is really not news. I can write a Carbon application right this second that attempts to delete the contents of your home directory on launch. I can name it "Coolest Song.mp3", paste an MP3 icon onto it, or simply include the MP3 icon as the applications default icon, as this "trojan" does, stuff it, and start sending it out to people.

It is social engineering, plain and simple. The ONLY "issue" is that the file can, deceptively, have a .mp3 extension while still being handled as an application. This is an artifact, obviously, of the old type/creator metadata handling: type/creator trumps extension. So, as I said before, even if this behavior is disallowed, I can still do EXACTLY the same thing, perhaps just without a .mp3 extension, and still fool some people with it.

The only thing that the trojan does is launch iTunes and masquerade as an actual mp3...but after its launched, the damage is already done. The trojan's behavior of actually appearing to open in iTunes will simple confuse people a little longer, to potentially do even more damage. But either way, the damage is done. This is such a non-issue that it's frankly pretty surprising.

One of Millennium's suggestions would actually be useful for this - it's really the only solution that would offer anything - and that is the idea of somehow further visually badging or identifying executables. Beyond that, there's not much that can be done.

The other important difference is that even if you craft a nifty little trojan and disguise it as a piece of shareware, an mp3, a graphic, or whatever, there is NO EASY WAY for it to propagate...it would be over before it even began. This is critical: Windows virii/worms/trojans generally try to rely on proven propagation techniques: relying on the inherent security shortcomings of Windows, relying on the ubiquity of Outlook, etc. This is another case in point why diversified platforms, and a strong security and permissions model - such as that of UNIX - is extremely valuable.

[piracy]

Originally posted by theolein:
The bottom line is that Apple has to get a patch out for this (at a minimum making the Finder display files which have "APPL" type file codes in the resource forks as applications). The reason that this is dangerous is that, in theory, this trojan would also work on .jpg extensions for preview and .rtf extensions for text edit. It is by no means a great feat to get people to download stuffed files of these types (for example: "Great huge wallpaper jpeg pic of Anna Kournikova nude! Compressed to make your salivating download time shorter!") and get them to unstuff them and double click them.

I just wrote to Apple about it.

Yes, this could "work" for ANY document type. I can make my malicious Carbon application, and give it any document icon I wish, with any file extension I wish. This issue is not new, and has not just been "discovered". What has happened is Intego is trying to ride this pony for all it's worth. But you are correct: some type of visual identification of executable files and/or some other quick means of universal identification of an application is the only thing that could really prevent this.

[car1son]

Originally posted by besson3c:
Were you sending the attachment from Sendmail/Postfix enabled Mac to another Mac through localhost, or were you using your ISP's SMTP server?

I sent it trhough myy ISP's SMTP server (as my ISP account) and retrieved it from my .Mac account. The OS X Mail and Entourage v.X MIME encodings are clearly cabable of preserving the bogus CFM info.

I can also retain the info by fordwarding the mail through a non-Mac system.
But I think it can't originate on a non-Mac.

Lesson: Don't double-click attachments.

[theolein]

Originally posted by piracy:
Yes, this could "work" for ANY document type. I can make my malicious Carbon application, and give it any document icon I wish, with any file extension I wish. This issue is not new, and has not just been "discovered". What has happened is Intego is trying to ride this pony for all it's worth. But you are correct: some type of visual identification of executable files and/or some other quick means of universal identification of an application is the only thing that could really prevent this.

Actually, the neatest thing to do, apart from patching the Finder (that must be done!) would be for the Finder to simply include some mechanism of detecting when a new executable is created from an archive (via the permissions for example) and do a chmod 644 on the .app folder or carbon application file, and then both request user authentification to be able to double click launch it as well as provide a warning about the dangers of this.

[alphasubzero949]

Originally posted by theolein:
Actually, the neatest thing to do, apart from patching the Finder (that must be done!) would be for the Finder to simply include some mechanism of detecting when a new executable is created from an archive (via the permissions for example) and do a chmod 644 on the .app folder or carbon application file, and then both request user authentification to be able to double click launch it as well as provide a warning about the dangers of this.

http://www.apple.com/macosx/feedback/

[eevyl]

Just in case anyone feels the urge of testing a large number of files to see if one is a trojan virus:

AntiAPPL

Free, of course.

[Developer]

Originally posted by theolein:
Actually, the neatest thing to do, apart from patching the Finder (that must be done!) would be for the Finder to simply include some mechanism of detecting when a new executable is created from an archive (via the permissions for example) and do a chmod 644 on the .app folder or carbon application file, and then both request user authentification to be able to double click launch it as well as provide a warning about the dangers of this.

I don't think users want to acknowledge each program start. That would be a big annoyance.

Also, a trojan horse doesn't have to camouflage itself as mp3. Could as well pretend to be a game, funny presentation, or even anti-virus tool.

[Millennium]

Originally posted by Developer:
I don't think users want to acknowledge each program start. That would be a big annoyance.

Oh, certainly not each time the program starts; just the first time. This could actually be something of a help, because if you know that MP3s aren't supposed to display this dialog, it would look suspicious if one were to suddenly display it.

I still believe that a large transparent badge, displayed over the icon of any valid executable, would also go a long way towards keeping users from being fooled in icon view. In the tradition of diamond-shaped icons for applications, perhaps a large diamond would make a good indicator.

Also, a trojan horse doesn't have to camouflage itself as mp3. Could as well pretend to be a game, funny presentation, or even anti-virus tool.

Indeed. But by disguising itself as an mp3 (and actually being a valid mp3), it becomes much harder to track down and eradicate. With a little work, this could actually be turned into a true virus, by scanning through a user's iTunes library and attaching itself to any mp3 files it finds. Opening the mp3 through iTunes is harmless, and so it would lay dormant for quite some time, but sooner or later one of those files is going to get double-clicked for some reason or another, and so the process would begin anew.

[hudson1]

Maybe Apple should include some type of file consistency check that must run when application is launched. It would compare type, extension, and icon (mayber other info?) and then display a warning if it detects that there is anything that's inconsistent among those characteristics.

[Developer]

Originally posted by Millennium:
Oh, certainly not each time the program starts; just the first time. This could actually be something of a help, because if you know that MP3s aren't supposed to display this dialog, it would look suspicious if one were to suddenly display it.

I think it would be better to sign applications, and let applications of vendors the user deems trustworthy execute without the hassle of allowing each individual app.

[danengel]

I think it would be better to sign applications, and let applications of vendors the user deems trustworthy execute without the hassle of allowing each individual app.

It should not only warn but simply make execution impossible. If you really want to run the application, get help from the Terminal, but many novice users must be protected from their ignorance.

[Kristoff]

Look, like Piracy said...this is simply social engineering, albeit a novelly clever example of it.

If you can trick people into double clicking an icon labeled anna_kournikova.gif, then you can trick people into double clicking an icon labeled hey_ya.mp3, or one labeled paris_hilton.mov just as easy.

The difference is that OS X doesn't have the same mechanisms (read ActiveX) and lack of security that makes these things such a big issue on that other platform.

Patch the finder, but it wont solve stupidity.

My .02

[ryju]

Originally posted by osiris:
IMO this threat is a BOGUS bunch of doo dooky dinky poo


thankfully

Now that's the first intelligent answer I've heard!

[theolein]

Originally posted by Developer:
I think it would be better to sign applications, and let applications of vendors the user deems trustworthy execute without the hassle of allowing each individual app.

Signing applications is good and well, but who is going to do the signing, Apple? You seriously expect every shareware developer to have to get his or her application signed by Apple? May as well buy a PC with Bill G's DRM lock-in then, because I honestly don't see much difference between forcing all developers to get their stuff signed by Apple and what Microsoft does.

[Millennium]

Originally posted by Developer:
I think it would be better to sign applications, and let applications of vendors the user deems trustworthy execute without the hassle of allowing each individual app.

The problem is, when you get into digital signatures, you need a centralized certificate authority. While this is viable and valuable for software delivery mechanisms, it must not be unleashed on the woftware itself, because it would give a central body far too much control.

[Developer]

Originally posted by theolein:
Signing applications is good and well, but who is going to do the signing, Apple? You seriously expect every shareware developer to have to get his or her application signed by Apple?

Developers can sign their applications themselves using a certificate from one of the many trust centers available (not Apple or any other single organization of course).

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

Just look at how many people fall for the old

http://www.citibank.com/<some really long string>:[email protected]

links in emails asking for their bank accounts.

[car1son]

Originally posted by car1son:
I tried sending it to myself (via SMTP thru my ISP and .Mac) from OS X Mail and retrieved it with Entourage v.X, and it's still an application.

I should have tried this in the other direction.

When receiving this via OS X Mail, virus.mp3 appears with a generic Application icon and a quicktime control slider. Clicking the slider actually plays the MP3 content! Double-clicking the attachment gives a warning that it is an application and allows you to cancel. That should help unsuspecting users a little.
I was wondering if this might be a result of the recent Security Update (which is installed, and listed Mail as an effected application.)

Entourage displays the attachment as an MP3 (iTunes) document.



Correction: The presence of the QT slider (as 2nd attachment) seems to result when I forward the message thru Hotmail, but not when I send directly Mail->ISP->.Mac->Mail. Then I only see the generic App icon (until I drag the icon to the desktop, when it resumes its MP3 document icon.) Odd that forwarding would change the attachments.

[Diggory Laycock]

Originally posted by Kristoff:
This whole thing is lame.

What a waste of time to even think about it.

I have had more productive meditation sessions pondering how they get the cream filling inside a Twinkie.

I should imagine it's some kind of injection process.

[wings_rfs]

I posted this somewhere before but forgot where ... oh well.

When any application is loaded from the Finder it first checks the file's resource fork for a resource containing the machine's MAC address (a number unique to every machine). If it is not present, up goes an alert telling the user exactly what application is about to run, that this is a new application and asks if the user wishes to continue. If yes, the Finder writes the MAC address into the resource so that on subsequent runs the alert is bypassed. No Trojan could be written that would bypass this check by having the resource already prepared with the user's MAC address since every MAC address is unique.

Whatcha think?