• On BNET: Bill Gates on the iPad
advertisement
April 12, 2004 7:30 AM PDT

More on the Mac OS X type/creator, .extension "trojan horse"

by CNET staff

Continuing our coverage of the MP3Concept (MP3Virus.Gen) potential vulnerability - which exploits a weakness in Mac OS X where applications can appear to be other types of files - we have a new folder action which checks for correspondence between a filename's extension and the type/kind.

MacFixIt reader Rick Bargerhuff writes "Simply attach the folder action to the folders where your downloads go to. The following is a comment I posted under the comment section on this article.

"This 'alert' has always existed in the Mac OS but has been under the radar for a long time until now. So I decided to code a Folder Action which I hope will ease Mac user's minds.

"The Folder Action will check any files or folders to see if a file's name- extension corresponds to the file's Type and kind. If it does not meet this criteria, the script asks the user if they want to quarantine the file. If the file does not have an extension and the file's type and kind indicates it is an application, the script acts as if the file did not meet the criteria. If the user chooses to quarantine a file, the script creates a folder named 'Quarantined' which is created inside the directory the Folder Action is attached to. More info is available in the read me."

The folder action can be downloaded from http://home.comcast.net/~c0ugar/files/Mismatch.sit.

Restricting application usage In order to prevent unsuspecting users from launching potentially harmful false MP3 files, MacFixIt reader Jack Pate suggests simply restricting application launch capabilities to a certain folder - namely the default /Applications directory.

"To nip this while thing in the bud, simply change the "limitations" of all your users to only applications in the Applications folder (and OS9 Apps, if applicable. . . ). It's is an easy 'check-box' setting, and should TOTALLY eliminate the threat, because it would prevent any executable code from being run outside these apps, while still allowing .sit files to open normally and EVEN 'real' MP3 files, because it would be launching a qualified app in the approved folder to play it."

OpenOSX Publishes Free TrojanDefuser Meanwhile OpenOSX has announced the immediate availability of TrojanDefuser, offering users "drag and drop operation that will render files suspected of being the recently discovered variations of the Trojan Horse 'MP3Virus.Gen' harmless, by making a copy of the suspected file without the resource fork, therefore eliminating the potentially malicious code and at the same time preserving the data fork of the file."

"If the software detects a potential ?Trojan Horse?, a copy of the file(s) that are suspect will be created in the same location as the original(s) starting with the prefix "SAFE_", ending with the original file name and leaving the original file intact. For example a ?disinfected? version of "virus.mp3" would become "SAFE_virus.mp3"". The tool is available for free download from http://OpenOSX.com/support/

Users finding suspicious files Via the methodology listed in Friday's edition, users are finding some strange files - oddly coming from Apple's own distribution.

Terrell Smith writes "I did a search in Finder on my HD for any file "Name contains .mp3" and "Kind: Application," and was surprised to discover that the old iTunes Sampler that came with the original iTunes has a file called "Max Graham Airtight.mp3" which is also a Classic Application. Creation date is Jan 22, 2001."

Symantec posts LiveUpdate file The update for Norton AntiVirus from Symantec encompassing the MP3Concept flaw has been posted via the company's LiveUpdate mechanism.

There is also a manual download link for the new definition.

As posted to Symantec's Web site: "MP3Concept is a proof-of-concept Trojan targeted at the Mac OS X platform, that is currently not seen 'in the wild.' It is not spreading or infecting Mac users. The proof-of-concept program does not contain any malicious payload such as viral code, ability to email itself or perform destructive functions such as deleting files. It only contains code to display a message box and mp3 audio data of a man laughing."

Feedback? Late-breakers@macfixit.com.

Resources

  • http://home.comcast.net/~c...
  • http://OpenOSX.com/support...
  • download link
  • Late-breakers@macfixit.com
  • More from Late-Breakers
  • Recent posts from MacFixIt
    iTunes 10 user interface sees some minor changes
    Apple seeds iOS 4.1 Gold Master to developers
    Possible fix for Harman Kardon iSub problems with PowerPC Macs
    Precautions to take before installing iTunes 10
    A reminder on how to reset your Mac's system password
    Mail messages appearing blank
    Adobe Lightroom update brings direct Facebook publishing; Camera Raw 6.2 released
    Weekly troubleshooting utilities update
    Add a Comment (Log in or register) (16 Comments)
    • prev
    • next
    by Lou Zer April 12, 2004 8:12 AM PDT
    The folder action only applies if you have (a) a file with a file extension not .app, and (b) has a type code of APPL. It won't apply if:
    (a) The file has no extension, but still looks like an MP3, JPG, etc.
    (b) The file has an .app extension, which the users can't see (even if they turn on file extension viewing)
    (c) The file looks like it has an extension of .mp3 (or whatever), but the dot isn't a classic period but some other character (a comma in the simplistic form, which most people won't notice is not a period) followed by a .app extension (which the user won't see).

    In all these cases, the file will look just like a file, but will run as an app.

    No matter how you cut it, this whole thing is still a whole lotta hype about nothing (or, at the very least, nothing new). Let's get serious here. This concept has been around for a decade or more. Its never been tried on a big scale, to the best of my knowledge, but has been fairly well known.

    Remember, the worst trojan seen so far has actually come from Apple themselves. iTunes v2.0 installer had a nifty built-in feature of deleting your entire hard drive if you dared do something stupid like have a space in the hard drive's name. (Well, and some would call OS X.3's firewire problems another trojan or virus, but that's neither here nor there).

    Wake me when some real news occurs.
    Reply to this comment
    by Doug Metz April 12, 2004 8:12 AM PDT
    <class="merchant"><span>&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by Lou Zer</i></div></class><br />
    LouZer said:

    The folder action only applies if you have (a) a file with a file extension not
    .app, and (b) has a type code of APPL. It won't apply if:
    (a) The file has no extension, but still looks like an MP3, JPG, etc.
    (b) The file has an .app extension, which the users can't see (even if they turn
    on file extension viewing)
    (c) The file looks like it has an extension of .mp3 (or whatever), but the dot
    isn't a classic period but some other character (a comma in the simplistic
    form, which most people won't notice is not a period) followed by a .app
    extension (which the user won't see).

    In all these cases, the file will look just like a file, but will run as an app


    Incorrect on all counts. The folder action isn't restricted to the Finder's view
    of the landscape, which should have been apparent given the script's ability
    to check Type codes (which the Finder Never shows the user). Given this,
    your points (b) &amp; (c) are incorrect. The info available for any given file
    includes a weath of information, not the least of which is the actual file
    extension applied to the file, regardless of the Finder's (and, therefore, the
    User's) ability to see it. Furthermore, had you read the description carefully
    (or bothered to look at the source AppleScript code), you'd also know that the
    folder action treats APPL files without extentions as Suspect. That's not to
    say that it's bullet-proof, but...

    Do try a teensy bit of forensics before posting this type of response.
    Reply to this comment
    by Lou Zer April 12, 2004 8:12 AM PDT
    <class="merchant"><span>&#62;&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by Doug Metz</i></div></class><br />
    I'll grant you that it will handle non-extension files. But I still don't see how it handles files ending in .app? You can't see these extensions in the Finder, so the user can't tell these are applications or not by just looking at them (without having to look at info or the kind column in the finder). Your script will ignore these (not that I can read applescript) because they do have an extension of .app. or is your script basically set up to tell you just whether a file is an app or not an app (which would have been simpler than trying to map things against a file extension and checking type codes)?

    My point is, if the file is a .app, but has no type code (.apps generally don't), then there's no protection unless it assumes ALL files are unsafe.

    Second, how does it handle shell scripts?
    Reply to this comment
    by Doug Metz April 12, 2004 8:12 AM PDT
    <class="merchant"><span>&#62;&#62;&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by Lou Zer</i></div></class><br />
    The script uses AppleScript's 'info for' command, which returns a record of
    several attributes. When 'info for' is called on (for example) Chess, this is
    what is returned for your use:

    name:"Chess.app"
    creation date:date "Saturday, September 27, 2003 4:30:32 AM"
    modification date:date "Saturday, September 27, 2003 4:30:32 AM"
    icon position:{0, 0}
    size:3.5839E+6
    folder:true
    alias:false
    name extension:"app"
    extension hidden:true
    visible:true
    package folder:true
    file type:"APPL"
    file creator:"mbch"
    displayed name:"Chess"
    default application:alias "HardDrive:Applications:Chess.app:"
    kind:"Application"
    short version:"2.0"
    long version:"Chess Version 2.0, Copyright 2003 Apple Computer, Inc."
    bundle identifier:"com.apple.Chess"

    The folder action uses information in this record to determine what is an app
    and what isn't. Pretty reliable for ID purposes, though there are things that
    can be slipped past the casual user.

    &lt;more to come&gt;
    Reply to this comment
    by Doug Metz April 12, 2004 8:12 AM PDT
    <class="merchant"><span>&#62;&#62;&#62;&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by Doug Metz</i></div></class><br />
    As for Unix Executables, I got this info on the 'jar' executable in my Java 1.4.1
    folder:

    name:"jar"
    creation date:date "Tuesday, April 6, 2004 9:35:51 AM"
    modification date:date "Tuesday, April 6, 2004 9:35:54 AM"
    icon position:{0, 0}
    size:3.624E+4
    folder:false
    alias:false
    name extension:missing value
    extension hidden:false
    visible:true
    package folder:false
    file type:""
    file creator:""
    displayed name:"jar"
    kind:"Unix Executable File"
    locked:false
    busy status:false
    short version:""
    long version:""

    The folder action would ignore this file, though a quick mod to the 'kind' test
    would take care of that. Keep in mind that Unix Executables won't have
    resource forks, and the exploit that triggered this whole thing requires a
    Carbon application (ie: resource fork and APPL file type). Interestingly, the
    file type and creator codes (universally 4 characters each) on this file consist
    of four ASCII zeros, even though they appears here as simply "". The actual
    dangers of Unix Executables are beyond the scope of my current knowledge,
    but I'm working on it. ;o)

    Anyone?
    Reply to this comment
    by cougar718 April 12, 2004 8:12 AM PDT
    <class="merchant"><span>&#62;&#62;&#62;&#62;&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by Doug Metz</i></div></class><br />
    Hey Doug,

    If you think it would be a good idea to make it so Unix Executables are found,
    let me know.

    Thanks
    Reply to this comment
    by Doug Metz April 12, 2004 8:12 AM PDT
    <class="merchant"><span>&#62;&#62;&#62;&#62;&#62;&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by cougar718</i></div></class><br />
    I certainly don't think it'll hurt, though I really think this sort of spoof ought
    to be handled by the Finder when the file is double-clicked. Same premise as
    your script, but different. ;) If it is an application with an extension, the
    Finder should know when the two are mismatched and respond with an alert
    when it's launched. Or something.

    But like I said, I'm not sure how (or if) a Unix Executable can have a resource
    fork and a media extension... Time to do some reading.

    Nice work, BTW. Thanks for the effort.
    Reply to this comment
    by Kirk McElhearn April 12, 2004 8:12 AM PDT
    <class="merchant"><span>&#62;&#62;&#62;&#62;&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by Doug Metz</i></div></class><br />
    I'm told that this method of a Trojan could work with extensions other than
    APPL - for example, an appe could run as well. Any thoughts?
    Reply to this comment
    by 123 April 12, 2004 8:12 AM PDT
    <class="merchant"><span>&#62;&#62;&#62;&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by Doug Metz</i></div></class><br />
    Carbon apps have no extension. Everyone has carbon apps.

    The Finder seems to display any app name with a extra . in with the .app (so
    making a trojan.mp3.app would show trojan.mp3.app). However,
    1. I can call it MySong.app, and it will show as MySong. I can also call it
    MyPicture.app (or NakedLesbians.app) or ReadMe.app. Either you catch all
    .apps, or none of them.
    2. There are a few dot-characters in unicode; the closest (i.e. most believable)
    is probably 0x2024, "ONE DOT LEADER" (add "character palette" to your
    keyboard menu, view: unicode, unicode blocks, basic latin, click the period.
    click the 'character info' triangle, it will be one of the 'related characters').
    This way, I can call it MySong,mp3.app (replace , with ONE DOT LEADER), and
    it will look like "MySong.mp3".

    This game of fooling people (windows doesn't show extensions by default,
    MySong.exe with an mp3 icon would work for a lot of people) will only end
    when OS X only allows launching of apps with .app (and shows it to you) or
    displays a warning and tells you to authenticate apps first (this is the better
    way).

    And in windows, shortcuts (.lnk) appear to have no extension too, so you can
    make a mysong.mp3.lnk with an mp3 icon, which runs "deltree c:\". You just
    hope nobody notices the shortcut arrow.
    Reply to this comment
    by Lou Zer April 12, 2004 8:16 AM PDT
    Two other things:

    First, how does one restrict application usage to the app's folder? The reader says its just a click of a box, but where's the box? Netinfo? System Preferences? Get Info window?

    Second, what type of scanning did NAV include in their app? Is it specifically looking for this code signature? Is is tied to MP3 concepts (where updates would be needed for the first JPG or MP3 variant)? Is it tied to the extension vs. type check? Is it something else?
    Reply to this comment
    by JohnnyMnemonic April 12, 2004 8:16 AM PDT
    <class="merchant"><span>&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by Lou Zer</i></div></class><br />
    You can restrict the abilities of a user through the "Accounts" pane of System
    Preferences.

    You can only restrict the abilities of non-admin users, however.

    If you really wanted to be able to do this with an admin user, I imagine you
    could change their group ownership, and subsequently change the group
    modification rights to all related files. That's too much trouble for me to work
    through, however, so it's left as an exercise for the reader.
    Reply to this comment
    by cougar718 April 12, 2004 10:58 AM PDT
    Hello everyone,

    I updated the Folder Action because it had a BUG that wasn't it allowing to
    find a suspicious file nested inside a group of folders, for example...

    ~/Desktop/Mismatch/virus.mp3\ folder/VIRUS1/VIRUS2/VIRUS3/virus.mp3

    The download link now reflects the current version.

    Thanks - cougar
    Reply to this comment
    by ubernaut April 12, 2004 12:49 PM PDT
    If you unstuff something with this kind of file inside of it the script creates an
    unkillable warning dialog. thanks for the good work other then that it seems
    cool.

    uber
    Reply to this comment
    by cougar718 April 12, 2004 12:49 PM PDT
    <class="merchant"><span>&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by ubernaut</i></div></class><br />
    Hello Uber,

    I contacted you via Email but I guess it has not reach you yet. Your
    explanation does not make sense because if you unstuff the archive from the
    folder with the Folder Action attached to it, it finds the file and asks if you
    want to quarantine it. Simply choose "Yes" or "No" from the dialog. I have
    been able to reproduce an "unkillable" dialog like you have described.

    Rick
    Reply to this comment
    by FriscoFrog April 12, 2004 6:35 PM PDT
    Mismatch 1.0 and 1.1 fail to work for me in OS 10.2.8. I get as far as attaching the action to the folder, but nothing happens when challenged with the test virus. I communicated this to the author but he seemed perplexed. Anyone have any idea why this script won't run in Jaguar?
    Reply to this comment
    by Wild West Studios April 12, 2004 6:35 PM PDT
    <class="merchant"><span>&#62;</span><div class="datestamp"><i>This is a reply to a previous comment by FriscoFrog</i></div></class><br />
    Yeah I found the same thing. I'm also running 10.2.8 and it does not
    work for me, either. Hopefully it is a simple fix.
    Reply to this comment
    (16 Comments)
    • prev
    • next
    advertisement

    About MacFixIt

    MacFixIt is CNET's troubleshooting resource for all things Mac. The information here helps you navigate the ins-and-outs of Mac ownership with how-tos, troubleshooting information, news, reviews, and more.

    Add this feed to your online news reader