Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Mac OS X > First virus threat or hoax?

First virus threat or hoax?
Thread Tools
Mac Elite
Join Date: Mar 2001
Location: Madison, WI
Status: Offline
Reply With Quote
Apr 8, 2004, 03:28 PM
 
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.
I do not like those green links and spam.
I do not like them, Sam I am.
     
Mac Enthusiast
Join Date: Oct 2000
Status: Offline
Reply With Quote
Apr 8, 2004, 03:47 PM
 
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.
     
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
Apr 8, 2004, 04:08 PM
 
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.
( Last edited by piracy; Apr 8, 2004 at 04:29 PM. )
     
Fresh-Faced Recruit
Join Date: Mar 2004
Status: Offline
Reply With Quote
Apr 8, 2004, 04:27 PM
 
You also have to find some way to keep the resource fork intact. Otherwise it won't work.
     
Addicted to MacNN
Join Date: Sep 2000
Location: Isle of Manhattan
Status: Offline
Reply With Quote
Apr 8, 2004, 04:32 PM
 
IMO this threat is a BOGUS bunch of doo dooky dinky poo


thankfully
"Faster, faster! 'Till the thrill of speed overcomes the fear of death." - HST
     
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Apr 8, 2004, 04:46 PM
 
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.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
Apr 8, 2004, 05:00 PM
 
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.
     
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Apr 8, 2004, 05:19 PM
 
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.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
Professional Poster
Join Date: May 2000
Location: Urbandale, IA
Status: Offline
Reply With Quote
Apr 8, 2004, 05:31 PM
 
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).
"Yields a falsehood when preceded by its quotation" yields a falsehood when preceded by its quotation.
     
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Apr 8, 2004, 05:54 PM
 
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.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Apr 8, 2004, 05:58 PM
 
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  (op)
Mac Elite
Join Date: Mar 2001
Location: Madison, WI
Status: Offline
Reply With Quote
Apr 8, 2004, 06:31 PM
 
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.
I do not like those green links and spam.
I do not like them, Sam I am.
     
Mac Enthusiast
Join Date: Nov 2001
Location: Arizona
Status: Offline
Reply With Quote
Apr 8, 2004, 06:46 PM
 
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?
     
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
Apr 8, 2004, 06:49 PM
 
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.
     
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Apr 8, 2004, 06:51 PM
 
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.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Online
Reply With Quote
Apr 8, 2004, 07:02 PM
 
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.
     
Mac Enthusiast
Join Date: Nov 2001
Location: Arizona
Status: Offline
Reply With Quote
Apr 8, 2004, 07:39 PM
 
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.).
     
Mac Elite
Join Date: Feb 2001
Location: Vancouver, WA
Status: Offline
Reply With Quote
Apr 8, 2004, 07:52 PM
 
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.
Rick Roe
icons.cx | weblog
     
Professional Poster
Join Date: Jan 2001
Location: Manchester,UK
Status: Offline
Reply With Quote
Apr 8, 2004, 08:05 PM
 
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.
     
Mac Elite
Join Date: Sep 2000
Location: in front of the keyboard
Status: Offline
Reply With Quote
Apr 8, 2004, 08:09 PM
 
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...
signatures are a waste of bandwidth
especially ones with political tripe in them.
     
Mac Enthusiast
Join Date: Nov 2002
Location: Barcelona, Spain
Status: Offline
Reply With Quote
Apr 8, 2004, 08:22 PM
 
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
My Blog & Photos
PowerBook (Ti) 1Ghz 1Gb 60Gb SD
     
Mac Enthusiast
Join Date: Nov 2002
Location: Barcelona, Spain
Status: Offline
Reply With Quote
Apr 8, 2004, 08:28 PM
 


Get Info show that the "MP3 File" is actually an application.
My Blog & Photos
PowerBook (Ti) 1Ghz 1Gb 60Gb SD
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Online
Reply With Quote
Apr 8, 2004, 08:47 PM
 
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?
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Online
Reply With Quote
Apr 8, 2004, 08:48 PM
 
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?
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Online
Reply With Quote
Apr 8, 2004, 08:51 PM
 
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?
     
Mac Enthusiast
Join Date: Nov 2002
Location: Barcelona, Spain
Status: Offline
Reply With Quote
Apr 8, 2004, 09:00 PM
 
DP
My Blog & Photos
PowerBook (Ti) 1Ghz 1Gb 60Gb SD
     
Mac Enthusiast
Join Date: Nov 2002
Location: Barcelona, Spain
Status: Offline
Reply With Quote
Apr 8, 2004, 09:02 PM
 
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?
My Blog & Photos
PowerBook (Ti) 1Ghz 1Gb 60Gb SD
     
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
Apr 8, 2004, 09:21 PM
 
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.
     
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Apr 8, 2004, 09:49 PM
 
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.
     
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
Apr 8, 2004, 09:52 PM
 
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.
weird wabbit
     
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
Apr 8, 2004, 09:59 PM
 
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.
     
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
Apr 8, 2004, 10:04 PM
 
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.
     
Mac Enthusiast
Join Date: Nov 2001
Location: Arizona
Status: Offline
Reply With Quote
Apr 8, 2004, 10:49 PM
 
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.
     
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
Apr 9, 2004, 12:51 AM
 
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.
weird wabbit
     
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Apr 9, 2004, 12:58 AM
 
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/
     
Grizzled Veteran
Join Date: Dec 2000
Location: Málaga, Spain, Europe, Earth, Solar System
Status: Offline
Reply With Quote
Apr 9, 2004, 06:39 AM
 
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.
     
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
Apr 9, 2004, 07:37 AM
 
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.
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Apr 9, 2004, 08:30 AM
 
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.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
Dedicated MacNNer
Join Date: Aug 2002
Status: Offline
Reply With Quote
Apr 9, 2004, 09:39 AM
 
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.
     
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
Apr 9, 2004, 10:18 AM
 
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.
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
Mac Enthusiast
Join Date: Oct 2000
Status: Offline
Reply With Quote
Apr 9, 2004, 10:22 AM
 
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.
     
Mac Elite
Join Date: Sep 2000
Location: in front of the keyboard
Status: Offline
Reply With Quote
Apr 9, 2004, 12:38 PM
 
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
signatures are a waste of bandwidth
especially ones with political tripe in them.
     
Professional Poster
Join Date: Aug 2002
Status: Offline
Reply With Quote
Apr 9, 2004, 01:00 PM
 
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!
     
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
Apr 9, 2004, 01:26 PM
 
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.
weird wabbit
     
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Apr 9, 2004, 01:36 PM
 
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.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
Apr 9, 2004, 03:57 PM
 
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).
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
Mac Elite
Join Date: Sep 2000
Location: in front of the keyboard
Status: Offline
Reply With Quote
Apr 9, 2004, 06:19 PM
 
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>:808093494939393@attacker.com

links in emails asking for their bank accounts.
signatures are a waste of bandwidth
especially ones with political tripe in them.
     
Mac Enthusiast
Join Date: Nov 2001
Location: Arizona
Status: Offline
Reply With Quote
Apr 9, 2004, 09:14 PM
 
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.
( Last edited by car1son; Apr 10, 2004 at 01:18 AM. )
     
Professional Poster
Join Date: Oct 2001
Location: London
Status: Offline
Reply With Quote
Apr 10, 2004, 07:06 AM
 
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.
     
Fresh-Faced Recruit
Join Date: Dec 2002
Status: Offline
Reply With Quote
Apr 10, 2004, 08:59 AM
 
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?
     
 
Thread Tools
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Top
Privacy Policy
All times are GMT -4. The time now is 06:20 PM.
All contents of these forums © 1995-2015 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2015, Jelsoft Enterprises Ltd., Content Relevant URLs by vBSEO 3.3.2