Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'A warning on a new destructive 'trojan horse'' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A warning on a new destructive 'trojan horse'
Authored by: FlashBIOS on May 12, '04 06:04:28PM

As a long time computer programming I thought that I should contribute my 2¢.

This type of exploit (and it is not really an exploit) is not limited to AppleScript and does not have to be done with the 'rm' command.

With very few exceptions, all computer languages have the ability to delete files. This is because file creation and deletion is (obviously) a very important part of the functioning of many computer programs.

The idea of AppleScript checking for the execution of shell commands won't solve this problem because they could use the 'delete' term of the Finder's dictionary. I.E. the deleting of a file is built right into AppleScript, and it needs to be for AppleScript to be a useful language.

Renaming the 'rm' command won't solve this either. Besides the previously mentioned reasons, the 'rm' command is basically a wrapper to the 'unlink' BSD system call. To delete a file in C/C++ is as easy as calling unlink(path) where path contains the path to the file or directory you want to remove. Many programs on your computer are making this very call right now. And in two minutes anyone with the most elementary of knowledge in C can make the same program to delete a user's home directory. The same is of course true of Objective-C, the language many of Mac OS X's programs are written in, with the '- (BOOL)removeFileAtPath:(NSString *)path handler:(id)handler' method.

The solution is not patching anything or displaying any dialogs. The immediate solution is simple: don't be stupid. These programs have existed since Apple's System 1 because it is not a virus, exploit, or a limitation of the operating systems design. It is the reality we have to face when we run programs on our computer that we don't know the workings of. This user was stupid (to be blunt). Despite what he said to the press, I would bet my hat that he didn't think he was downloading a demo, he intended to seal Office. Because of his intent, we went to a seedier side of the Internet where the likely hood of coming across one of these programs is greatly increased. He downloaded a program that he did not know from an untrustable source. Don't misunderstand me: I fully blame the author of the program that deleted this users files but if the user hadn't been "stupid" this wouldn't have happened.

A far reaching solution is for Apple to redesign its security model. The current file permission system we have in OS X has been around for a very long time and computers are much more capable now. For example the National Security Agency has designed a version of linux SELinux (I believe that is the name) that implements a very exciting new way of doing things. There is even a test server made publicly available to the world where any one can create a root account and encourages people to try and break things. They cannot because of the very advanced rights system that operating system uses.

[ Reply to This | # ]
A new model
Authored by: agraboso on May 13, '04 01:31:51AM

Much more than 2¢, FlashBIOS.

The discussion in other comments goes always around tricks and roundabouts that only "protect" against a very particular line of code (and at the cost of most probably disturbing the normal functioning of the system).

Computers are just machines: they do what we humans tell them to do. Malicious people tell computers to do malicious things. And this will always happen, no matter how "perfect" the OS any particular machine is running. So, the basic principle is and will always be: Beware of Greeks bearing gifts. As it was said before.

But we still must try to make it harder for the bad guys to fool us. The Unix model has been around for a long time now. We have had time enough to notice its pros and cons and we should try to use this experience to improve it. Perhaps we are wasting our energies in this whole discussion about aliasing rm or checking system calls when we should use them in finding new models inheriting from our beloved Unix.

I didn't know anything about SELinux (by the way, here is the NSA link about it), but I will surely have a look on it. Let us see some new ideas.

[ Reply to This | # ]