Mac OS X Trojan Horse Infects MP3s
frequnkn writes "The Mac News Network reports that Intego has anounced an update to their anti-virus app for snagging the first Mac OS X Trojan horse, MP3Concept (MP3Virus.Gen), which exploits a weakness in Mac OS X where applications can appear to be other types of files."
In six years, Intego has made a name for itself in the Internet security and privacy market for Macintosh.
I always wonder where the sources are for the majority of viruses. It is quite ironic that a company selling you a fix happens to find the problem and releases the solution for the low price of 59.95. Yet a goggle and Symantec Security search didn't yield anything about MP3Virus.Gen. Hmmm - it's awfully nice they fixed this virus so fast.
I can stand that.
Does my speculation about the RIAA's involvement in the creation of an MP3 trojan put me in the tin foil hat crowd?
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 numerous logistical, technical, and statistical reasons.
It is a real concept. There is an example of the trojan, or "virus" (sic), here: http://www.scoop.se/~blgl/virus.mp3.sit
However, it seems that this may be at best questionable, as the "proof of concept" is nothing more than a standalone CFM application that has been given a creator type of 'APPL' (recognized by Mac OS X as a Carbon application), but with the file extension '.mp3', the standard mp3 icon, and the contents of an mp3 (which Mac OS X displays to the user 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 a CFM application, the file needs to be transported in such a way as to keep the resource fork intact, massively reducing its utility.
I predict a future security update with disallow this behavior...
This does not change the fact that Mac OS X is fundamentally and philosophically far more secure than alternatives.
.. and I just bought a G4 PowerBook too!
That's it, I'm selling this, maybe I'll get one of those Sparc laptops instead..
- Cowboy
what, what?
That noise you heard was all the mac zealots falling of their soapboxes. ;-)
j/k, who loves ya baby!
Quidquid latine dictum sit, altum viditur
I thought in unix, everything was just a file!
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8 &oe=UTF-8&safe=off&frame=right&th=631707378ffe9292 &seekm=blgl-5D750C.02150821032004%40news.bahnhof.s e#link6
It appears that this is merely a proof of concept virus, hence, it is utterly benign. It was not made with any malicious intent, but to demonstrate one way that OS X could be exploited. The discussion group is concerned with making OS X more secure, not less.
Somehow, Intego got wind of it and blew it out of proportion, but I suppose it is theoretically possible that future viruses could be modeled on it. However I'm sure that Apple could, even more quickly, release a security update that fixes this.
I suppose I'll start to panic as soon as apple acknowledges it, rather than take the word of a company trying to sell me anti-virus software.
I'm switching to Windows!
What kind of OS X user would be caught dead using such ancient, PC-originated technology (and I use that term loosely) as an MP3?
It's bad enough that they'll be shunned by all their iPod-wearing, dual-CPU-owning, Mac cabal member friends, but now their computer get pwned? Talk about kicking them while they're down.
True story.
What this article doesn't mention is how (or if) the code gets around the normal OS X restrictions requiring that one enters an administrator's password. Even if applications can be hidden, I question the amount of damage they can do... Surely nobody will enter an admin password requested by an ".mp3" file.
Besides, this isn't a virus so much as a security flaw. Why pay $60 for software when Apple will surely release a patch soon?
Oh, and for all the PC assholes who are currently saying "In your face, mac zealots" or whatnot--nobody claims that OS X is bulletproof--no computer system is. Nevertheless, it seems to be a lot more secure than, say, Windows, which has security problems all of the time.
It was just a matter of time before someone used it maliciously to confuse the line between instructions and data.
I can see the fnords!
Heh... Interesting that the first trojan horse/virus yet to be seen for OS X uniquely exploits the discordance between the "Classic" pre-OS X way of specifying file types (File Type/Creator metadata) and the new, inherited-from-Windows, file extension method.
.mp3 extension... the Finder thus displays an MP3 icon for it yet launches it as an application when the user double-clicks.
The basic gist of this trojan from what I've read so far (there is very little information aside from what Intego has on their own web site) is that it is a file with type AAPL (executable application) but with an
What this basically comes down to, then, is the Finder making the wrong decision as to how to present the file to the user. Specifically that it presents it in one way, but acts upon it (when double-clicked) in the other. Whether it should first obey the deprecated file type metadata or the file extension is left to be argued about... what's certain is that it should always behave with the file the same way it presents it. I predict a bug fix for this will be in OS X shortly.
No one ever said it was physically impossible for Mac OS X to have a trojan...the only thing that even MAKES this a "trojan" is the fact that the file can *appear* as an ordinary MP3. Writing an application that can be destructive is no difficult task; it's just that this can appear to be an MP3 due to a shortcoming in the way OS X displays and handles Carbon/CFM vs native file type information. A security update can easily fix the shortcoming. Still, 1 trojan vs. thousands? I'll take Mac OS X, thanks...
Somebody on macnn.com pointed out this: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8 &oe=UTF-8&safe=off&frame=right&th=631707378ffe9292 &seekm=blgl-5D750C.02150821032004%40news.bahnhof.s e#link6
I have my doubts about this trojan, as I opined on my website at destination-life.com, but there is one problem: this proof of concept at this link:
At Google Groups
I opened the file in BBEdit, and it appears that there is in fact executable code in the file, but it doesn't appear evident to me how the binary code would be executed if the audio file is opened inside of a music player.
Hopefully this ends up being a hoax, or at least some more details come out soon.
Once worked for a local mac service shop that sounded the red alert for a purported virus the owner dubbed "MySound". It turned out to be nothing more than a sound file installed by scanner software...He just ended up with egg on his face. Seemed like a quick way to sell more copies of AntiVirus if you ask me.
What's relevant here is now that this has exposure (and we all know that /. == exposure to those who matter), how quickly will Apple respond and rectify this by issuing a patch?
Here's wagering that they don't sit on it like M$ has been known to do, if not for any other reason that M$ has a far greater volume of virsus/trojan horses/etc. to deal with!
-Nanter
This is nothing new... people have been doing this for years on Windows. OS X lets you hide file extensions too, so MyMusic.mp3.app can show up as MyMusic.mp3. The article seems a little misleading at first -- the ID3 tag isn't executed, its a full fledged application that contains an MP3 file.
.mp3 extension, rather than showing the file as an application, leading users to believe that they can double-click the file to listen to it. But double clicking the file launches the hidden code, which can damage or delete files on computers running Mac OS X, then iTunes to play the music contained in the file, to make users think that it is really an MP3 file . While the first versions of this Trojan horse that Intego has isolated are benign, this technique opens the door to more serious risks.
It would take me about 15 minutes to write my own "trojan horse" of this nature... Don't make a big fuss over nothing.
From the MacNN article:
The company says that Mac OS X displays the icon of the MP3 file, with an
Sanity is not statistical.
We needed an OS X virus just to liven things up! The ratio of viruses in the wild to lab viruses leads one to believe that the Anti virus companies created some to keep them in business. The WildList should be enough to keep all the Antivirus companies on their toes now.
Have you Meta Moderated t
The last big 'virus' scare for the mac was a number of years ago with the 'autostart worm'. As I understood it, it was an app that took advantage when you put a music cd in, it would automatically launch and play. The system was simply fooled into thinking the worm was a CD and not an application.
I have been surprised there haven't been more exploits using this method. I stick a music cd in any computer now (mac/win/*nix) and the OS launches and tries to play it.
Also, many windows install disks have the autoinstaller application which, I suppose, could be spoofed into launching automatically too, by a malicious code writer. It automatically launches simply by inserting a CD.
Am I correct in assuming all modern OS have some file validation routine to check these autostart/autolaunch applications?
Hey, leave comments about my mother out of this!
This virus sucks unless it has ogg support. Jeez! Mac OS X is so lame..
Trojans aren't new in the Mac world, of course. There have been viruses made for the original Mac OS, but very, very few in comparison to, say, MS-DOS and Windows: Approximately 50 Mac OS viruses compared to 20,000+ viruses and their ilk in the Windows world.
The method in which this trojan infects isn't new: Windows viruses often hide their true extension in the same way as this empty-payload Mac OS X trojan.
What is significant is what a payload-laden trojan could do the today's Mac OS world. As a tech, I get to see a fair audience of Macs in use and what software they use. The very concerning part is that very few (my estimate: less than 1 in 50) Macs use ANY kind of antivirus software.
Not that you can't find any: Aside from Intego (who make a fine firewall as well as their virus products), you can get Norton AntiVirus from Symantec and Virex from Network Associates. Yet, most of us don't own any AV software.
That's bad for two reasons. One: While most Windows malware we Mac users may receive by mail are harmless to our Mac OS X systems, we remain Typhoid Mary-esque carriers to other PCs. Two: Our complacency in saying that "Macs don't get viruses" does not ensure that we will not experience one later.
That "later" is now.
Further, the "security through obscurity" protection is gone with the move to OS X. It's just a UNIX OS now, no longer a relatively-closed OS, which means there are more people who are UNIX-savvy who can create malware than before. (Fortunately that also means there are plenty of Good Guys who can spot this stuff before Apple or AV vendors are made aware.)
While I doubt there will be lots of new Mac attacks soon, I would not wait until one shows up with a nasty payload. Buy some AV software and keep puttering along. I'm sure there's some ass out there with too much time on their hands who, like the guy who took the Word Macro "Concept" virus, added a payload and sent it on its way, who will love to make some pitiful Mac users suffer.
Also, consider creating a regular user account, which cannot install software. In the event that you do open something with a payload on that account, hopefully OS X's permissions will stop any attempts to change any file or program except those in that account's home folder. Thank God for the UNIX permissions system.
Vos teneo officium eram periculosus ut vos recipero is.
The resource fork is a remnant of the pre-OS X days. Pre-Mac OS X files, including applications, had two "forks": data and resource. When Mac OS X was created, it had the ability to run its own native applications, as well as two types of "Carbon" applications, Carbon being an API that allowed portability of applications using a subset of the old Mac OS programming APIs. One type of Carbon application, CFM, uses a resource fork for, among other things, file metadata. One of these pieces of metadata is something called Type and Creator. "Type", in this case, is set to APPL, and thus identifies itself as an application. While OS X decides to display the file as an MP3, the launching behavior is that of an application - just an oversight. The issue I was referring to was the resource fork must be kept intact in order for the file to still work - and any type of binary transfer WITHOUT special handling or compression (e.g. StuffIt, MacBinary, etc) will strip the resource fork and render this little "trojan" useless.
Also, if you knew the first thing about Mac OS X, you'd readily admit that the design philosophy and fundamentals of the OS do make it far, far more secure than, say, Windows.
assuming this is a serious question, try this for explanation.
On of the many woes of being a Mac user is that we do not have the multitude of viral applications that Windows users have. Now that we have our first trojan, we are on the path of being like Windows users. However, it is my fear like most Windows applications, we are going to have to wait months and months before we get our next one...
Strange women lying in ponds distributing swords is no basis for a system of government.
"It is quite ironic that a company selling you a fix happens to find the problem and releases the solution for the low price of 59.95. "
/Inigo Montoya ]
[ Inigo Montoya ]
I don't think that word means what you think it means.
[
That's not ironic. It may be, to tinfoil-hat-wearers, SUSPICIOUS, but it's not ironic at all.
The traditional Mac OS file system has two forks, a data fork, which is where normal data (like an MP3) lives, and a resource fork, which contains stuff like window designs, icons, bitmaps etc. for applications. I guess the executable code also lives there as well.
.app extension) which is a problem, although Windows does the same by default, it is possible to turn it off in Windows. Personally I'd give all executables a special label highlight to show that they're programs.
Depending on what you do with the file, the resource fork can be stripped easily, which is why Apple switched to a bundled format for most Mac OS X stuff, and why stuff like binhex and macbinary exist, to combine both parts of a file into a normal data file.
This does hilight an annoyance with Mac OS X, that applications never have an extension shown in Finder (old style Mac ones don't have them, newer bundle ones hid the
10 PRINT "LOOK AROUND YOU ";
20 GOTO 10
The Trojan description is:
1) Make a valid MP3 file
2) Make the beginning of the file a JMP instruction (assembly code) that tells it to jump to the point in the MP3 where the ID3 tag is stored.
3) Put a virus in the ID3 tag.
What's to prevent this from working on Windows? It's a brilliant, and scary plan... . It would be especially effective if linked on a website, as Windows accepts MIME-types first and extensions second now.
From my read of their PR page about this, it sounds like something they entirely fabricated themselves to sell their software. There is nothing in the wild and no reports on respectable security sites, just Intego saying they "isolated" something and you should buy their FUD^H^H^Hproduct. As others have pointed out, a trojan is possible on any system if you can get the user to jump through elaborate enough hoops. So the next time you download an unknown MP3 (or whatever) file with an intact resource fork from an anonymous source and give it executable status so you can double-click it instead of just adding it to your iTunes library (or playing it in Finder with a single click in column view), be glad you also shelled out money to Intego so that you are protected from your own stupid and unnecessary actions! That it's come to this shows just how hard it is for anti-virus types to make money on the Mac.
Microsoft today palced a strange ad in the Seatle times classifieds. The ad called for programmers with mac experience who have no scruples about developing malicious software.
I tried for 5 years to come up with a clever sig...only to realize that I am not clever.
You find it ironic that a problem is found by people who make their living looking for such problems???
I have a hard time seeing why the parent is flamebait, especially when given a smile.
He *is* right in that what you have here is an honest-to-God architectural security problem with the Mac OS. It isn't a coding bug or a stupid user -- Apple clearly defines how to determine file type in their specs, which will now need to be revised.
And I think he's pretty accurate in claiming that this *does* embarass a lot of people that were making semi-bogus security claims about the Mac OS.
Had he said "Yes, now we can all tell that Mac OS X security sucks", then sure, he'd be flamebait. But he was spot-on accurate in his statement. Modding him down because you don't like the truth of something he's saying is just silly -- a religion, a text editor, or a computing platform that cannot stand up for itself on its own merits should not have you trying to suppress valid criticisms of it. If it can, it doesn't *need* you trying to suppress valid criticisms, because those are minor compared to the benefits of the platform.
May we never see th
ResEdit.
Is this rock and roll, or a form of state control?
A .Mac subscription comes with a free copy of Virex (McAfee) along with all the other free apps.
Personally I'm just going to download the Virex update when it becomes available, but since I've now gotten used to installing countless Security updates via OS X's Software Update app without hearing a whisper about any vulnerabilities I'm guessing Apple's ahead of the game.
Personally I like the fact that we now have a trojan - proves at least that we're not defended entirely by obscurity as some might suggest :)
One virus or Trojan every three years? I can stand that.
Can you understand that past performance does not indicate future performance?
Also your sample size is questionable. Classic Mac OS' history is irrelevant to Mac OS X. Mac OS X is a far more interesting and potentially lucrative target. It combines a highly capable Unix environment (home turf/holy grail for hackers) with a usually unsophisticated (wrt security) users who have no admin to watch over them. This is only the beginning, get used to that.
OS X has been out for three years. This is the first trojan/virus (giving this the benefit of the doubt). Ergo, 1 every 3 years.
Yeah, there's no admin to watch over them/us. What's your point? The system will protect the user as much as it can (have to authenticate to install/write to system areas, or create sockets on privileged ports). It's a bit more secure than Windows where a user needs a nanny standing over her slapping her wrist and saying "don't do that" or "don't open that". If it does become a target, it's more hardened. It's not like Windows saying "take me, big boy."
It should be noted that the would-be virus code is not executed by OS X when opened with an audio application. It skips over the JMP (or however they implemented the hack) and just plays the audio content.
If you throw virus.mp3 into your favorite p2p sharing system (or a web site, or most sharing methods other than AFP) the downloader will only get the data fork. That's why they had to put it in a .SIT archive first. Now you have to include code to rearchive the trojan before passing it on.
To do self-propagation right, go for pure data fork. Maybe AppleScript. A simple version would just read from AddressBook.app and spew to Mail.app. Bonus points if you detect/use other email clients too, including OS 8/9.
Like I said, this is trivial and stupid... but I spent a few minutes and made a different version of this trojan. Check it out below, it "looks" like a jPG file (if you have "always show file extensions" off), but is really an application with an embedded JPG file which it open after printing some benign messages to the console.
.app package so it would be kind of hard to distribute it via a P2P mechanism or something, since it needs to be .zipped (or whatever) to transfer it as a single file.
It is
Anyway, check it out:
fakeJPGTrojan.zip
Sanity is not statistical.
There are no tiger attacks in my area and it's all because this rock I'm holding keeps the tigers away.
Type and creator are not stored in the resource
fork nor the data fork. You could think of them
as a third, fixed-size fork. At least, that's what
Siracusa of Ars Technica wrote.
Ben "You have your mind on computers, it seems."
I noticed alot of people going on about, "I'll now be more suspicious of any mp3's I get like this", but what no one has mentioned is that it aint just mp3 files you could do this trick with, it is probably a wide array of file types.
This is a self launching application in sheeps clothing, who says it has to be an mp3 flavored one, and it doesn't have dependancy on the app to run, only that it be there.
No, no, that wasn't a virus, just 10.3.2. (Note to would be flamers - I have a mac and love it!)
I wonder if the virus can progate as a shared iTune? So if someone on a corporate lan added that to their shared iTunes and someone played I wonder what would happen?
"With enough memory and hard drive space, anything in life is possible!"
Second, an OS X application is actually a directory with '.app' trailing the name. This is possibly the dumbest thing that I've ever seen Apple do recently. Not only is it cumbersome and extremely resource intensive, but it is a glaring security hazard.
A.) Apple didn't do it - NeXT did.
B.) How is this cumbersome?
C.) Resource intensive? Bollocks.
D.) Glaring security hazard? Bollocks again. Double bollocks.
I downloaded this sample virus and tried to open it, but Panther told me I didn't have permission to open it. So, unless you're logged as admin it looks like it ain't gonna work.
If I didn't have absolutely NOTHING to do, I wouldn't be here.
The file is a CFM application. As others have pointed out, this means that it has a resource fork which it needs in order to be able to run. Thus, it must be downloaded as a compressed file. If the resource fork is stripped, it is harmless, as the payload will never be executed.
Its name ends in ".mp3", and the included icon is copied from an iTunes MP3 file, but its type code is APPL, an application. The data fork is a valid MP3 with PowerPC executable code inside the ID3 tags. When given to iTunes or another MP3 player, it simply plays the included sounds without executing code. When double-clicked on from the Finder, the surrounding bits of MP3 file appear to be ignored and the code is executed. The payload for the proof-of-concept displays a dialog box, then tells iTunes to play the file itself, presumably via AppleScript.
When double-clicked, it shows up in the dock as an application, though this could be suppressed in an actual hostile trojan just like many utility programs do. In the Finder, if one is using column view, it is identified as an Application instead of an MP3 File, and its icon is shown instead of a QuickTime-style playback bar for previewing the contents.
In terms of an actual exploit, the only thing going on that is even possibly questionable at an OS level is the presence of other stuff in the data fork before the Joy!peffpwpc tag. I am not certain if this is allowed in the definition of what a PEF executable is supposed to look like. Aside from that, there is nothing else that is tricking the OS into doing something it shouldn't do, only legally included information that is deceptive to a user who is not looking carefully at things.
The same reason there is "N'Sync".
BeOS virus ? Something to keep you awake at night... BeOS could also set arbitrary icons for files to disguise their real types. This problem is nothing new.
--
I romp with joy in the bookish dark
- Download file with a name like Yeah-Usher.mp3.sit with your favorite downloader.
- Decompress said StuffIt file. If you use Safari and have "Open "safe" files after download" or use Camino and have "Automatically open downloaded files" checked you can skip this step
- Open up the file in attempt to view/listen to it
- Suffer ill effects of worm
I'm not too worried even if a Security Update isn't released to fix the problem. I suppose a worm of this sort will affect the sort of people that open attachments from strangers and type in their administrators passwords despite warnings against such actions. For them there isn't much you can do except take their computer away.I'm a loner Dottie, a Rebel.
NeXT did it for a good reason:
.app directory so all the resources, bitmaps, and supporting files are in that one directory. That is why I can reinstall OS X and have MS Office X and all my other applications still work without reinstalling everything. I suppose they could still do fat binaries as well if they ever decided to do so.
NeXTSTEP ran on four different hardware platforms and had fat binaries. Within the foo.app directory, there'd be foo-moto, foo-386, foo-sparc, and foo-hpux binaries. The OS would then attempt to execute the appropriate binary for the hardware platform the OS was running on.
OS X uses the
I tried every decent and legal way I could think of to resolve the issue w/the business before I rented the chicken suit
no i think the mach-o objects (the code) is fat. one file contain the executable, while the directory contain all the datas... especially the interface definitions. in theory you could copy English.interface directory, cant remember the actual name and do the interface translation in the interface builder.
No, he's referring to Fahrenheit 451 -- you know, where the firemen are the ones starting the fires, not putting them out... Mix this with a little cut-throat capitalism, and you have a conspiracy theory (a damn good one at that)! :^)
Slashdot's first reaction to VMware
Average Windows users know command lines?! What kind of fucked up world do you live in?
The average Windows user doesn't know how to map a network drive; doesn't know how to properly unmount a USB Storage Device in Win2k; doesn't know how to CANCEL PRINT JOBS if there isn't an annoying window from the bullshit software that pops up when you print.
The average Windows user doesn't know how to format a disk; doesn't know how to look at a full mail header, doesn't know how to Mail Merge.
The average Windows user doesn't differentiate between hard disk and "memory"; doesn't know how to clear the Recent Documents; doesn't know how to change their password.
The average Windows user hasn't used net send, ping, or even winipcfg. They don't know where to change the resolution on their monitor; they only change the Background from a right-click menu in Internet Explorer.
They have never intentionally used an F-Key that wasn't modded to do something special on their multimedia keyboard. They have no idea that Ctrl-F6 will switch between panes, so you don't need to click back and forth when designing a table in Access.
They don't know that Print Screen copies their screen to the Clipboard. Hell, they don't know what the Clipboard is.
The average Windows user doesn't know what Temp files are; has no concept of file permissions, can't make a Pivot Table; doesn't know how to uninstall programs; Has at least two things in their system tray they can't identify; has never performed a full backup of their data; and certainly has never touched their Registry.
Even tech support often doesn't know enough about the command line, like using "~1" doesn't mean you don't need the extension, or that Program Folder 8.1.1 becomes Progra~1.1 or that you can type the whole damn thing in quotes.
Maybe ten years ago the average Windows user knew something about the command line, but not anymore.
On Windows we had Trojans of this level of complexity -- really little more complex or interesting than distributing an AOL password phisher as porn and/or a game -- ten years ago. This can effect anything from Palm OS up to a mainframe. It'd be something to be scared about if a worm came out for OS X that can infect without any user action.
MacOS has always had a virus scanner, even though most viruses were for Windows. Disenfectant was written by John Norstad at Northwestern UNiversity. Great freeware app, and protected agasint all known mac viruses, of there were literally on the order of 20 or so (while there were thousands of Windows ones). The best part was the Monty Python foot that came down in the About Box.
This kind of reminds me of adding extensions to the resource fork of otherwise innocuous system files in system 7-9.
One April Fools Day I installed a completely juvenile little extension called "Mouseturds" on my roommate's computer. But inside of "Mouseturds" I inserted an extension that reversed all of the text in the system. Inside of another file in the system (I believe it was directly in the Finder), I installed a second instance of the text-flipping extension.
When he first started using his computer, all of the text looked normal, but his mouse kept doing this terribly juvenile thing. "Cute, really cute." He said, removing that extension. You can't imagine his befuddlement when upon rebooting all of his text was sdrawkcab, simply for having cleaned his system. In the next few hours he drew up all sorts of crazy theories about dependencies, mounting extensions from the trash can, automatically installing programs when something is removed, and a mythical hidden second system folder. I didn't have the heart to tell him to watch the extensions list on the startup screen more carefully, but I didn't have the jaw if he decided to start swinging. He was not at all amused.
Moral of the story: No one thing is ever one thing on an apple system.
Other moral of the story: Never take a smart-alec joker as a roommate.
The ______ Agenda
In NeXTStep V1.0( and I think 2.0), the entire application was stored in a Mach-O format file. Ultimately, there were resource issues involved in trying to keep the entire application and it's resources in a single Mach-O file, which resulted in this being splitup into a diretcory containing the resources, and the Mach-O file retaining the executable data required by the system loader.
That's not all that different from how classic Mac OS apps were stored in different resource areas of a file.
Because Microsoft Office (the mac port) adds the functionality of vbs-worms!
This comment does not represent the views or opinions of the user.
It actually disgusts me to see the usual OS bashing bullshit that continues to go on and on and on and on around here. My OS is better than yours Nah Nah Nah. Nice. Can't we have more intellectual conversations around here? I've been coding since the late 80's being weened on x86 assembler on DOS, Q'nix and yes - even 16/32 bit windows - and to see comments like "the average windows user can barely tie their shoelaces" bullshit irritates me. To be quite honest, computers to the average joe are scary. Just because they don't know how to mount a drive or know what shl ax,1 means doesn't mean their stupid. Its like asking /.'s to describe a date with a woman.
Want to know something amazing? I've been using Windows since it came out and have YET TO BE INFECTED WITH A VIRUS. Yes you heard right. I have NEVER been infected by a Trojan, Worm or Virus. Be a dumb user - you get burned. Simple.
Its like every 5th post is about how shitty Windoze is. Lets drop this dribble. No one is gonna win this argument.
Geeks of the World, Unite!
open up a terminal:
./Applications/Mail.app/Contents/MacOS/Mail
man sudo
and
man su
then:
sudo - dumbuser
This isn't the first OSX virus.
I think the first one was back during version 10.0 and was named something like "The Simpsons". If I remember correctly, that one was written in Applescript and it was fairly benign.
I believe the only damage it did was send out the contents of your address book or something like that. Not really disastrous.
The Intego Virus Barrier software just flags as "infected" any CFM executable whose name ends in a common file extension... which is why it STUPIDLY flagged as viruses the BMP, PCX and PNG plugins for Photoshop Elements. Which means it does not even check for a dot and something else before the file extension.
Proof (jpg)
Can you say "crappy" ? I'm sure you could.
Maybe we deserve this world ?
I seem to recall that common Macintosh viruses were things like MDEF (menu definition) viruses or MBDF (menubar definition) viruses or WDEF (window definition) viruses. These are the names of certain kinds of code resources on Macintosh systems that could be used to define a custom look-and-feel in certain places where necessary. To hook up an MDEF virus and get it to execute, you would insert an MDEF resource into the program (*very* easy to do), and then modify one of the MENU resources to use that MDEF to draw itself. (similarly for MBARs with MBDFs and WINDs with WDEFs). There were also certain resource numbers you could choose to hide the corresponding system resources while running the program, and you wouldn't have to do anything else to change the program.
The linked article (and most coverage of this trojan) is very misleading. This trojan does not delete files, propagate itself, or infect other files. The press release from Intego just says that a trojan like this could do those things. Read the press release for yourself.
Intego Press Release
The important thing to realize here is that Mac OS X, while very secure, is not perfect. And no matter what OS you are using, you should be very careful what you double click! Let's hope Apple nails this quickly!
The resource fork is not CFM-specific, and is not where metadata goes. Metadata, like the type and creator, are stored along with info like the filename. A file can have this metadata without having a resource fork.
A resource fork is used for extra data. Pre-OS X applications store dialogs, sounds, pictures, icons, strings, and even program code in the resource fork. All files on Mac OS X are capable of having resource forks, this is used by programs like BBEdit which store cursor & window position in the resource fork of text files you create.
Mac OS X is only capable of running one type of application binary, the Mach-O executable. When you run a CFM (Code Fragment Manager) application, launch services will run the 'LaunchCFMApp' program transparently. Normal CFM programs require a 'cfrg' resource in order to function, as well as a 'carb' resource to launch outside the Classic environment. CFM applications aren't necessarily Carbon, but that's by far the most common case.
The program isn't all that special. It has a custom icon, like every other application, but the icon looks like an MP3. If you transfer it without archiving it with Stuffit or MacBinary, the type & creator get killed (can't launch) and the resource fork goes away (no custom icon, can't launch). Since the data fork is a valid MP3 file, when you launch the stripped version it will open iTunes and play. You can also strip the file by going to the command line, and running 'cp virus.mp3 virus2.mp3'.
The 'cfrg' (Code FRaGment) resource is usually created automatically by development tools. It specifies where in the data fork the application code resides. So it's trivial to create an application that is also valid as a different kind of file.
I suspect it will catch the kind of people who put '.' in their $PATH, browse slashdot as root, and open email attachments in Microsoft Outlook.
Oh, and don't think that Mac users haven't had *problems* with viruses, as any Hypercard programmer will tell you (I hated MerryXmas virus).
. . . just give us your credit card number and everything will be fine.
But seriously; they paint the situation much worse than it currently really is, because they want ordinary users to be frightened of getting a virus. And that's because people who are frightened of getting viruses buy anti-virus packages.
It looks like someone noticed a potential security flaw to do with the way MacOS X presents files and file types to the user. He asked around on a Mac programming group to make sure he wasn't being paranoid, people there confirmed it was possible and one even made a test case (totally benign - it runs code but does nothing else). Here's a link to that thread on google groups.
Intego caught wind of this, and immediately issued a press release describing how the sky is falling, noone can trust anything any more, claiming credit for the discovery, and by the way have you noticed we sell a product which will prevent infection? Buy it now!
The .mp3 was just a proof of concept. Compression is how a lot of windows viruses in the loose work in very similar means now, as many mail servers now block file formats like .exe . Yes, most people won't be fooled by a .mp3.sit but what about something like a .doc.sit?
Marxism is the opiate of dumbasses
NeXTSTEP did not run on four different platforms. OPENSTEP might have - NeXTSTEP did not.
And they never used 'fat binaries'. Apple did, NeXT did not. The whole idea of subdirectories under 'Contents' such as 'MacOS' contravenes this - they had different directories for different binaries at best, but remember, NeXTSTEP did not use HFS+, they used UFS, so there was no way they could have made a fat binary anyway.
The directory as an app only means you have a different model for application development. They saw no reason to bake everything into the same file so you got things that were only accessible by products such as Resource Workshop and the like.
The presumption is as well that few standalones, even on other platforms, are true standalones, and so - especially with the NSBundle class at your service - you can create and manage a single self-contained entity.
Yes, you could have multiple binaries within foo.app; but these are not 'fat'; they're distributed into different subdirectories. Big difference.
Cocoa apps are a security hazard, but then so is X11. Cocoa apps can be compromised through their input managers, the Objective-C runtime, and the Apple services menu. Which is why no Cocoa app should ever run SUID root: anything invoked will be root too.
But that being said, Apple have about the most secure platform going today. SUID stuff is taken care of being the scenes by console apps which are much more difficult to compromise, and security awareness is very high.
If I were to put my money on exploiting either Cocoa or X11, I'd go with X11.
and to see comments like "the average windows user can barely tie their shoelaces" bullshit irritates me. To be quite honest, computers to the average joe are scary. Just because they don't know how to mount a drive or know what shl ax,1 means doesn't mean their stupid.
;)
I understand there's a fear factor, I work face to face with the average windows user every day, in their home. Not knowing how to mount a drive is one thing, very forgivable. Not even eyeroll-worthy. It's when they get in a panic because their sound card 'stopped working' only to discover that they had been turning the TONE control rather than VOLUME on their speakers. Now that's sad. I don't say *most* average users are like this (well, not without data to support me), but they do certainly abound.
I hate OS wars too. But the fact is, the average Linux user (oh, I should mention, I'm not one) is a Linux user partly because they are comfortable with having to know some things about their machine in order to use it. You know, Old School, like back in the day when you simply didn't HAVE a computer if you weren't interested in delving into it. They would tend to be the sort of person that enjoys having to learn something in order to make good use of it. I believe that the majority of people do *not* want to keep filling their heads. To many people that's what school was for and that part of their life is done. It's sad, but it's a choice made for the sake of comfort. I can respect it that way, there's a lot of other things they know perhaps.
I did an install once for a Lawyer (an intelligent man, one must presume), who became upset when he discovered that our high-speed access advertized as "One click and you're there" (or something) wasn't true. Because you have to double-click a desktop icon (to open a browser or whatever) he was almost going to cancel the service. He was getting installed purely on the pressure of friends, as he had gone years without email. And he was mad as hell about the whole thing. He got really mad when I didn't have paper documentation for Internet Explorer to leave with him. I pointed out where the Help was, and that just seemed to piss him off more. He *resented* being forced to learn something new, and I tried to tell him that anything worthwhile requires some learning. I asked him if he had ALWAYS known how to drive a car. No of course not, at some point he had to do a bit of reading, get some experience, do some practice. From the look in his eye at this point I realized I was traipsing into sass-mouth territory and just dropped it. The computer was given to him by a friend, and thank every god that it wasn't running Linux.
There's no fixing them, but at least they pay us to fix their stuff for them.
Can't we all just get along?
NS 3.3 ran on four platforms. That was the last version I used, and I distinctly remember it. There were even NeXTSTEP utilities that "thinned" out these fat applications and only left the thin executable you needed.
I tried every decent and legal way I could think of to resolve the issue w/the business before I rented the chicken suit
Most OS X boxes will have been installed with default settings.
Most OS X boxes will be used by only one person.
Most of these people will be running as a user in the admin group, since that's the type of user that is created during the installation process.
Users in the admin group can sudo to root.
So, the assumption that the trojan will run as the default user created during install, which is in the admin group and can sudo things to UID 0, is completely reasonable. Heck it wouldn't even qualify as "small", let along "big".
Nextstep did run on four platforms, and NeXT did use fat binaries. The binaries for the architectures were together in one MachO binary file, each in a different MachO segment. NeXT's fat binaries didn't use the resource fork like Apple's did.
.lproj directories for interfaces for different languages.
... [ ... [-create] [-thin arch_type] [-replace arch_type file- ... [-remove arch_type] ... [-extract arch_type] ... ... [-output output_file] [-segalign ...
Commandline programs, which have no directory bundle, could be fat, because the architectures were just concatenated. Mach just goes to the appropriate segment to find your computer's binary.
There was a tool called 'lipo' which was used to remove architectures from a binary, and otherwise manipulate them.
lipo as in liposuction, from 'fat binary'.
The directories you're thinking about are perhaps the different
lipo is still in OS X, apparently unchanged.
NAME
lipo - create or operate on fat files
SYNOPSIS
lipo [-info] [-detailed_info] [-arch arch_type input_file]
input_file]
name]
[-extract_family arch_type]
arch_type value]
The lipo command creates or operates on ``fat'' (multi-architecture)
files. It only ever produces one output file, and never alters the
input file. The operations that lipo performs are: listing the archi-
tecture types in a fat file; creating a single fat file from one or
more input files; thinning out a single fat file to one specified
architecture type; and extracting, replacing, and/or removing architec-
tures types from the input file to create a single new fat output file.
Someone should point out that the distinction that you're making is in name only. The actual codebase is the same, rebranded as "OPENSTEP" when they published their API for open implementation. For all non-marketroid intents and purposes, NeXTstep did run on four architectures. I had the pleasure of using it on i486, an HP "Gecko" PA-RISC workstation, and one of those noisy Tadpole SPARC laptops.
And although the code segments were not interleaved within the same file in the way that you're thinking, the actual term was "fat binary" both inside NeXT and within the user community. There was even a tool called "lipo" (as in liposuction) to strip out the architectures that you didn't need. It still lives in /usr/bin on MacOS X today.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Sorry to burst your bubble, but the whole 'app is really a directory' thing is a SOLUTION to the 'resource fork' storage problem. And it allows for cleanly implemented multi-platform 'fat' binaries. Apple's Classic fat binaries were kludgy, the CODE resource fork held the 68K binary and the data fork held the PowerPC binary, hardly extensible.
I've got an OSX install on purely UFS, and sure enough, it allows you to pack x86 and PPC binaries (or multiple PPC/X86 binaries, for optimization/bitness) into the same *.app so you can have one application file that executes on multiple architectures. It might not be Apple's hacked-up old kludgy way to get a 'fat binary' but it's effectively the same result but done MUCH cleaner and capable of living on many diverse file-systems.
Imagine how cool it would be to have ONE shared 'applications' folder mounted read-only on all your clients, the x86 clients execute the x86 code from camino.app and the PPC machines execute the PPC code from the same place. It would be an administrator's utopia!
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
NextStep ran on Motorola 68k (Next slab and cube), PA RISC (HP workstations), Sparc (Sun workstations), and Intel (specific PC's). Applications could be compiled fat on any of the four platforms and run on all four platforms with no modification.
jfs
The only thing worse than a Democrat is a Republican.
...on Windows... I pre-ordered the port once I heard about it...
Now if only Duke Nukem Forever would drop...
We apologise for the fault in this post. Those responsible have been sacked. -- Signed RICHARD M. NIXON
From what I've read so-far, this is not a virus or a trojan horse at all. It's a concept of social engineering. The idea is that you can make an attachment look like one thing and be another.
A virus spreads without your intervention - AFAIK this doesn't.
A trojan horse pretends to do one thing while doing another - AFAIK this doesn't.
I know, right now some of you are jumping up and down and getting ready - or have already - hit the reply button and have all manner of argument.
Let me point this out:
A trojan horse pretends to *do* one thing while *doing* another. This doesn't pretend to be an MP3 file - it just looks like one - nor from what I read is it actually playable in iTunes - so it's not an MP3 - it's an application.
Also it doesn't spread by itself - though it conceivably mails copies of itself to others if you launched it, so it's not a virus.
Back to my original statement:
So.Hope you've stopped being huffy, and got to this part - what do you do about it? For starters, don't launch things you get from people you don't know or don't expect.
Second, don't launch things you get from people you don't know or don't expect.
From my perspective this is just an attempt to create a marketing need for anti-virus software for the Macintosh.
Here endeth the lesson....
(PS. I've you've got something to rebuke the above, I'm all ears - I don't profess to know everything about everything, but I'll confess I know a lot about a great many things to do with computing - hint: I've been doing this for a few years :-)
(Second hint: My first computer was a Commodore Vic-20)
|>>?
Okay but that is not really necessary on Darwin anyway because it uses Mach-O instead of something like ELF (most modern UNIX-likes) or XCOFF (basically what the PPC data fork code really was prior to MacOS X) and this allows the same binary FILE to have copies for various architectures in it. Check out:
This came from NeXT too. WhatDid you know about the ARCH variable and the automounter? Do a man automount on solaris say. This is how you can create a map in NIS for /foosw say, where /foosw/bin is different for sparc and x86 while /foosw/include are the same say. Then you have dirs like /export/foosw/bin-x86, /export/foosw/bin-sparc, /export/foosw/include (or you may like to use a structure like /export/foosw/x86/ and /export/foosw/sparc/ with symlinks pointing up a dir for common stuff) which you export over NFS. On solaris check-out isaexec,
isalist, and friends to see how to have different optimized verions of the same binary. (The trick there is with subdirs like sparcv9 etc.) Each other OS (and sometimes it is a compiler-toolchain provided trick) handles this in its own way. You can even have optimized dynamic libraries, in elf just link with the appropriate -R options creating special dirs for the different targets. In solaris you may be able to be even more nifty about this all. Do this sometime on a recent solaris box:
Take a look at AT_SUN_PLATFORM. Now do:Take a look at and this should give you an idea of how to do something similar.Anyway, the thing you wish for has been solved a long time ago, and in a more clean fashion, without resorting to treating applications like directories.
I chose UFS fo my desktop for three reasons:
1. Case sensitive.
2. Thought it would be more resistant to corruption.
3. To see if it had any other advantages or disadvantages.
What I found was that it's a lot slower on laptops, but about the same real-world speed on desktops. Several third-party apps needed TLC to work right, because case sensitivity broke them. Cloning using Carbon Copy Cloner doesn't work with UFS.
I still use that UFS desktop, but I think next time I wipe it I'll go HFS+. I heard I can enable case-sensitivity in HFS+ now, so the benefits of HFS outweigh those of UFS for me now.
I'd like to see Apple implement resource forks as a plugin for reiser4 and then make darwin/OSX work on top of it. I think reiser4 would kick HFS+ arse.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails