Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Rincewind42 said:
I agree. It may spoil the aesthetics of some people's icons, but it is a small issue compared to clarifying what a file is to the user. Although this would have to be done a bit differently for documents (only superimpose the mini-icon on a document with a custom icon. After all, it'd be kinda strange to see an MP3 with a mini MP3 icon over the full sized one :) .

Come to think of it, you'd only need to tag one of the two. If application icons all had a mini-icon superimposed, they'd clearly be distinguished from document files. For example, the MP3 icon would end up looking something like this (in the three different sizes):

iTunes-mp3%20thumb.jpg
iTunes-mp3%20big.jpg
iTunes-mp3%20small.jpg


for this virus...
 
Rincewind42 said:
iTunes & QuickTime mean nothing in the context of this application. They could fail to play the file and you would still be owned. The exploit relies entirely on the user double-clicking the file itself, not on anything Quicktime or iTunes does with the file afterwards.

Baloney. That the file plays successfully is the stealthy aspect of the trojan's propogation vector. It's expected to be file-shared.

You can take any old carbon application and stick an .mp3 icon on it and have it install a back door, always have, but that's a different kind of trojan, not the one we're talking about here.
 
ClimbingTheLog said:
Baloney. That the file plays successfully is the stealthy aspect of the trojan's propogation vector. It's expected to be file-shared.

So tell me this, if I give you an application that you think is an mp3 file, and you open it, and nothing happens why should I care? You just opened my application, which is what I wanted. The fact that nothing happened that you can see is meaningless to me because you already gave me the chance that I needed to do any damage that I wish to do.

Sure, it may take a little longer to propagate, but in case you hadn't noticed, in it's current form it can't actually travel over P2P networks without being encoded in some form. And most trojans/virii don't rely on P2P networks anyway, either because it is not what the virus writer is after, or because it is faster and more reliable to reach a large audience over e-mail than P2P.

If the application wants to propagate, it will not rely on the user to do that (aside from getting the user to launch it). It will send itself out.

ClimbingTheLog said:
You can take any old carbon application and stick an .mp3 icon on it and have it install a back door, always have, but that's a different kind of trojan, not the one we're talking about here.

Not it really isn't. The only thing novel about this trojan is that it is a valid MP3 file as well as a valid CFM application. As it is, it can't propagate itself (by design I might add). But the fact that it plays an mp3 is only of comfort to the user - they may hold onto it longer because it is a valid mp3. But once the user double-clicks the application, it really i all over.
 
Rincewind42 said:
So really, it's a nice proof of concept that they can do this with a single-file CFM app, but the same kind of trickery is possible (and easier!) using Mac OS X's native MachO bundled application. And in the end even harder to detect, because you don't even need an extension, type or creator.

Yeah, but it's harder to spread your application on file sharing networks.
 
7on said:
Or just have Apple warn the user if the resource fork is different than the extension. Or throw away resource forks. Something, I think, Apple is trying to do. Considering they built in zipping in 10.3, something that does not include resource forks. And I wouldn't be surprised if Apple made UFS the default File system in it's OS. Might be a while though, but it is imminent. Not an extremely hard problem for Apple to fix.

Resource forks and extensions have nothing to do with each other. *Type* and extension is probably what you are looking for. And Apple has pretty much gotten away from the "death to resource forks" stance, so don't look for them going away anytime soon (and they can't stop launching single-file applications without users of legitimate apps created this way complaining loudly). And Apple won't make UFS the default file system, too much doesn't work properly with it (and HFSX was built to replace UFS in those places for which UFS was the previous default). Finally, zipping in 10.3 does preserve resource forks so that isn't a fix either.

Oh, and as I said a few posts ago, you can do something very similar and for any particular file type using a bundled application, i.e. a MachO Carbon or Cocoa application [you can have bundled CFM apps too]. And in that form, you can even get a better user experience because you can use any file type you want. So you could create a trojan that hops file types seamlessly spreading at will, or waiting for the user to send it themselves.
 
Because, if it is moved to anything but a HFS+ drive, the virus is ruined. Unless it is dmg compressed or sit compressed (the later would require Stuffit Deluxe to be installed).
 
ClimbingTheLog said:
Yeah, but it's harder to spread your application on file sharing networks.

It's no harder to spread my version over P2P than it is to spread the trojan that is the subject of this thread. However, my application can 1) reference more files 2) access all of Mac OS X's APIs natively and easily 3) Can be stored on non-HFS type file systems and still work on a Mac 4) requires FAR less knowledge to create. Oh, and it is also quite harder for the system to detect as a possible security threat (because it looks exactly like any other application on the system.

The nice thing about CFM applications on Mac OS X is that they all channel through the same helper application, which can do some verifications on it to determine if the application might be a security threat.
 
7on said:
Because, if it is moved to anything but a HFS+ drive, the virus is ruined.

Not if it is done from a computer running Mac OS X . In that case, a file Foo is copied with the data fork in Foo and the resource fork in ._Foo.
 
Rincewind42 said:
So tell me this, if I give you an application that you think is an mp3 file, and you open it, and nothing happens why should I care? You just opened my application, which is what I wanted. The fact that nothing happened that you can see is meaningless to me because you already gave me the chance that I needed to do any damage that I wish to do...

Yes, but the difference is if I double click on what appears to be an MP3, and nothing happens, I'll try to figure out what's wrong. I might choose to try to drag and drop it into QT or iTunes, at which point either I'd get an error message or nothing at all. Then I'd get really suspicious and maybe I'd look and see that the would-be MP3 is actually an application, realize that I just installed a virus (using 'install' rather loosely here), and immediately take steps to clean my system and protect my data.

On the other hand, if I double click on the would-be MP3 and it launches iTunes and plays a music file, as I expected it to do, I would be none the wiser that a virus had gotten into my system and it would then have free reign over my computer for some time to come...

That's the important difference.
 
Snowy_River said:
Yes, but the difference is if I double click on what appears to be an MP3, and nothing happens, I'll try to figure out what's wrong. I might choose to try to drag and drop it into QT or iTunes, at which point either I'd get an error message or nothing at all. Then I'd get really suspicious and maybe I'd look and see that the would-be MP3 is actually an application, realize that I just installed a virus (using 'install' rather loosely here), and immediately take steps to clean my system and protect my data.

On the other hand, if I double click on the would-be MP3 and it launches iTunes and plays a music file, as I expected it to do, I would be none the wiser that a virus had gotten into my system and it would then have free reign over my computer for some time to come...

That's the important difference.

That's all well and good, but unless the trojan is trying to do something long and complicated, it has likely already done whatever damage it is going to do. It has e-mailed itself to everyone in your address book, infected half a dozen files, and made itself at home. The fact that it's stay on your machine may be short is irrelevant because it has already sent itself to a new home.

I agree that the trojan is more likely to stay if it actually appears to be something that I want. But trojans and viruses are opportunistic by nature, they will use every opportunity they can find to do damage because they don't know when their next chance will be.
 
Snowy_River said:
On the other hand, if I double click on the would-be MP3 and it launches iTunes and plays a music file, as I expected it to do, I would be none the wiser that a virus had gotten into my system and it would then have free reign over my computer for some time to come...

That's the important difference.
Exactly!

Sushi
 
Hey, are we all so unnerved because somebody did, what everybody knew would happen anyway sooner or later?

Everybody boasting about the lack of viruses and so on for Mac OS X until a few days ago, perfectly well knew that it would be dead simple to write at least a trojan horse for OS X (taking a Carbon app and pasting a harmless icon on it).

But we all knew/thought/hoped it would never happen because:
a: OS X is so secure (and so rare) that it could not do much harm, therefore nobody would bother to write it (partly true, the harm is limited to the user's files, spreading is difficult) but somebody wrote a proof-of-concept one (without the spreading part) anyway
b: Nobody would dare to attack Macs, since they so wonderful computers (partly true, it's only a very benign proof-of-concept one)

Harm is done nevertheless, because of:
- bad press
- the great publicity is maybe giving the wrong people bad ideas (hey, why not write a real trojan horse, that ID tag thing is neat)

Cap'n Hector's laundry list could have been written last week by every knowledgeable person, answering the question what a trojan horse could do on a Mac.

Cap'n Hector said:
Based on my analysis of this:

Files it can delete without user interaction:
  • User files
  • Application files
Stuff it can do:
  • Run a server with a port over 1024+
  • Put itself in ~/Sites and e-mail links to itself. The links will be seen as MP3s by QT and treated as such…the payload should not be executed in this case.
  • E-mail itself to other computers. If e-mailed to a Mac running Mac OS X the computer will ask if you want to execute the file, giving options of "Open", "Save", and "Cancel".
  • Create a startup item to run at boot.
Getting a password will enable wiping the drive…

In short: This can cause damage, but it will be very hard to spread.
 
Rincewind42 said:
That's all well and good, but unless the trojan is trying to do something long and complicated, it has likely already done whatever damage it is going to do. It has e-mailed itself to everyone in your address book, infected half a dozen files, and made itself at home. The fact that it's stay on your machine may be short is irrelevant because it has already sent itself to a new home.

I agree that the trojan is more likely to stay if it actually appears to be something that I want. But trojans and viruses are opportunistic by nature, they will use every opportunity they can find to do damage because they don't know when their next chance will be.

You overlook a couple of things. First, not everyone has a full time connection to the 'net. If I double click a trojan when I'm not connected, and the trojan doesn't fool me into thinking that nothing's wrong, then I'll disinfect my machine before the next time I'm connected, and it'll never be able to spread.

Second, again, if I'm not fooled into thinking nothings wrong, even if I was connected to the 'net, simple suspicion of foul play could prompt me to isolate my machine (i.e. disconnect immediately), and, unless your trojan is tiny (I'll address that in a second) it'd could very easily not succeed in sending itself on to any more computers.

Now, why would I argue that your hypothetical trojan isn't going to be small? Well, it would have to have its own built in SMTP server. That right there could push it over 1MB. "But wait, what about the built in SMTP server in OS X?" you say. Ah, but as I already noted in an earlier post, the mailserver in OS X is not enabled by default, and would require a password to enable it. For that matter, I'm not sure that it wouldn't need an admin password to use an internal mail server...

So, your hypothetical trojan that doesn't continue to try to fool me into thinking nothing is wrong is aimed at a fairly small target group. First, it has to be someone using OS X. Then, it has to be someone who has an active internet connection most, if not all the time. Further, that internet connection most likely has to be highspeed. So, I'd say that, while this trojan might work, it wouldn't be all that effective.
 
Snowy_River said:
Now, why would I argue that your hypothetical trojan isn't going to be small? Well, it would have to have its own built in SMTP server. That right there could push it over 1MB. "But wait, what about the built in SMTP server in OS X?" you say. Ah, but as I already noted in an earlier post, the mailserver in OS X is not enabled by default, and would require a password to enable it. For that matter, I'm not sure that it wouldn't need an admin password to use an internal mail server.

1. The worm would not need a full blown mail server. Just a smtp engine which can be extremely small as smtp is a simple protocol. For example it's perfectly possible to use telnet as mail client. And worms in the windoze world that bring along their own smtp engine to spread are actually way smaller than 1MB. W32.Bagle.A@mm for instance had a size of 15,872 bytes.

2. To run such a smtp engine you need no admin rights. It's only connecting to another host and exchanging data with it. If you can read this your browser did the same. Of course if it wants to act as mail server for other worms it would need to listen on a port. If the local firewall is active an admin name and password would be needed to open a hole in it to be able to accept requests over the network.

3. There isn't even a dire need to bring along a smtp engine. Mail.app is very forthcoming when scripts ask it to send a mail. This of course would not be as fast or reliable as using a bundled engine.
 
space2go said:
3. There isn't even a dire need to bring along a smtp engine. Mail.app is very forthcoming when scripts ask it to send a mail. This of course would not be as fast or reliable as using a bundled engine.

Actually you couldn't use Mail.app, since it can't be scripted to sent attachments. But as you've already pointed out, bringing your own SMTP engine is simple, easy and painless.

This topic is starting to get a little scary though, as we've more or less put together a trojan in our minds. Probably the same thing that lead to the CFM/MP3 test case :).
 
Rincewind42 said:
Actually you couldn't use Mail.app, since it can't be scripted to sent attachments.

It does not acept a message body with the attachment already properly encoded in it?

Rincewind42 said:
This topic is starting to get a little scary though, as we've more or less put together a trojan in our minds.

But none that would do anything new. And anybody setting out to create a virus could get complete howtos on the net as opposed to some ideas in this thread. ;)
 
space2go said:
It does not acept a message body with the attachment already properly encoded in it?

Haven't tried actually, but the issue has come up on developer lists I frequent before and the consensus was that Mail didn't support doing that. But I'd still assume that a trojan/virus would bring it's own SMTP implementation simply so that it wouldn't have to rely on any particular e-mail client being setup correctly.

space2go said:
But none that would do anything new. And anybody setting out to create a virus could get complete howtos on the net as opposed to some ideas in this thread. ;)

Yea, but all of those are for Windows :D . I'm just hoping some idiot hasn't gotten the idea in their heads to go make one for real so they can get their 15 minutes.
 
Rincewind42 said:
Haven't tried actually, but the issue has come up on developer lists I frequent before and the consensus was that Mail didn't support doing that.

I just visited macosxhints and at once found an applescript that works and from which all user interaction can be removed easily. :confused:

But I too think this line of thought should stop here. ;)
 
space2go said:
I just visited macosxhints and at once found an applescript that works and from which all user interaction can be removed easily. :confused:

Hah! Figures :). (Either that or I'm misremembering the conclusion of that thread).
 
Snowy_River said:
Now, why would I argue that your hypothetical trojan isn't going to be small? Well, it would have to have its own built in SMTP server. That right there could push it over 1MB.
Don't assume coding will be that big.

Go hack code can be written in assembly which is a whole lot smaller.

Sushi
 
space2go said:
1. The worm would not need a full blown mail server. Just a smtp engine which can be extremely small as smtp is a simple protocol. For example it's perfectly possible to use telnet as mail client. And worms in the windoze world that bring along their own smtp engine to spread are actually way smaller than 1MB. W32.Bagle.A@mm for instance had a size of 15,872 bytes.

Ah. I was basing my estimate on how large other SMTP server software was that I've seen (typically >2MB). I've never looked at the code myself, so I didn't know how much could be stripped out of that.

2. To run such a smtp engine you need no admin rights. It's only connecting to another host and exchanging data with it. If you can read this your browser did the same. Of course if it wants to act as mail server for other worms it would need to listen on a port. If the local firewall is active an admin name and password would be needed to open a hole in it to be able to accept requests over the network.

That would explain my suspicions. I do work behind a firewall.

3. There isn't even a dire need to bring along a smtp engine. Mail.app is very forthcoming when scripts ask it to send a mail. This of course would not be as fast or reliable as using a bundled engine.

Of course, this would mean that Mail.app would launch when I double clicked the MP3 trojan, which would really freak me out. I'd know for sure that I had a virus then. Disconnect and disinfect.

I do agree that this seems to be becoming a Mac virus design meeting. Of course, all of this would be defeated if the Mac OS were to identify whether a file was a document or application in more than just list view, regardless of how it did it. (An alternative to the icon modification that I proposed earlier could be something as simple as making the file name italicized or bolded.)

Another scary though occurred to me, but maybe I shouldn't mention it...
 
Snowy_River said:
I do agree that this seems to be becoming a Mac virus design meeting. Of course, all of this would be defeated if the Mac OS were to identify whether a file was a document or application in more than just list view, regardless of how it did it. (An alternative to the icon modification that I proposed earlier could be something as simple as making the file name italicized or bolded.)

Actually it identifies it as an application in Column View also (showing Kind is optional in List View but Column view always shows the Preview). So we just need a fix for Icon view, and something that is always there for List view.
 
Rincewind42 said:
Actually it identifies it as an application in Column View also (showing Kind is optional in List View but Column view always shows the Preview). So we just need a fix for Icon view, and something that is always there for List view.

True. So what do you think is the best way to flag applications? Modify the icon or the title? Or both?
 
Snowy_River said:
True. So what do you think is the best way to flag applications? Modify the icon or the title? Or both?

I would say that either is acceptable, and both is great. Of course, it is really only academic until someone actually files a bug with Apple :) .
 
Rincewind42 said:
I agree that the trojan is more likely to stay if it actually appears to be something that I want. But trojans and viruses are opportunistic by nature, they will use every opportunity they can find to do damage because they don't know when their next chance will be.

I find that very interesting, the virus is aptly named. It acts like the virus that attacks our bodies.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.