Apple should not do anything about it, MHO.

As a user the protection is simply to alias 'rm' to 'rm -i' and you are safe even from that script, should you get it, in that before doing anything rm asks for your authorization.

Note that -i is a stronger option than -f so untill you say 'yes' to all rm attempts nothing will happen.

If you replace rm -rf with /bin/rm -rf in above example you are back to square one. In addition your alias will have to defined regardless of the shell the malicious script will use. Therefore, an alias is only a very weak protection in this case.

As a user the protection is simply to alias 'rm' to 'rm -i'

actually, i tried aliasing rm to "rm -i"; it works as long as you use rm without arguments, and will ask for permission. however, if you use rm -f, it bypasses the permissions, and just deletes the file. is it just me?

You're correct.

-i cancel PREVIOUS f, so if you created alias like rm -i and use it like
rm -rf it's essentially as /bin/rm -irf and it's exactly the same as rm -rf

This is so funny. This is nothing more than a basic unix command. It is on EVERY UNIX-LIKE OS and has been for years and years.

I'm as non-plused about this warning as I was about the last one from Intego, about another ‘exploit' that has been known about for years. I half expect them to breathlessly announce that there is a dangerous feature in Mac OS X whereby you can (gasp!) empty the trash without warning, and potentially delete important files!

Or better yet, warn that some nefarious person might write an AppleScript that would enable Postfix and then mail itself out to everyone in your Address Book, then give it the icon of a popular program. Oh, the horror! Start a letter writing campaign to Apple to get that awful, awful UNIX layer disabled immediately!

I am new to Unix. Can you pl tell me how to alias "rm" to "rm -i".
Thanks

Although it is no secret, it is better not to post things like this, IMO. I would guess far more people would try this script out on someone else's computer than the chance of someone actually getting this script through an email, image, etc.

Now you've just told both coders and non-coders alike how to walk into an apple store or university and cause destruction in less than 10 seconds at an apple keyboard.

?

...those who would do such a thing probably would find a way, anyway. But I do feel uncomfortable reading it here.

Actually, I disagree. You would probably learn this command within the first 30 minutes of your first ever Unix class. Trying to keep it a secret is like trying to prevent people from understanding why something so simple as pulling a trigger or lighting a match can be devastating and used maliciously, which makes them sitting ducks for the sorts of socially-engineered computer 'tricks' that are just now appearing on the Mac horizon (and are much more difficult than viruses to prevent since they rely on loopholes in *humans* instead of computers).

Any mac sys admin worth anything knows to not allow basic users access to the terminal.

-Dogcow "moof!"

People who are malicious at heart are going to find far worse things to do to others than tricking them into executing rm -rfd ~

That's misleading. Sure, it looked like it was in the ID3 tag info but it's not a real ID3 tag, it was just benefitting from the way an MP3 file is constructed to make itself both an MP3 file and an executable.

As a side note, I once ran across an example of a .gif file that was also a .zip file. It was a picture of a dinosaur, but if you changed the extension from .gif to .zip you could decompress it. The way it worked was a .gif keeps information about the size of the file in the header, but a .zip keeps a table of the information at the tail of the file. That way you can just append a .zip file onto the end of a .gif and you have a file that's both! Cute, eh? Oh, and the .zip file was the original DeCSS code. This file was on the gallery of DeCSS obfuscations.

By the way, -r arguement DOES NOT mean remove the top level directory, it means RECURSIVE REMOVE which will remove all directories below the start point, i.e.: to rm -r * would blow away the current directory, files and ALL BELOW IT AS WELL. Subtle but important point.....

Sorry, I meant to type it that way, but re-reading it, it's not clear that's what I was saying :). So I changed it a bit to hopefully reflect the proper definition.

-rob.

I have been looking for clarification about rm -rf. Are my following assumptions correct?

rm -rf ~/
removes your home directory and everything in it

rm -rf /
obviously deletes everything it can

rm -rf ~/*
removes everything in your home directory and /home (or /Users) and /
this is the one I would like clarification on, and I don't want to try it
(In other words, is this effectively the same as "rm -rf /" in most cases?)

Thanks.

no, rm -rf ~/* is an exact synonym for rm -rf ~. The shell will interpret the ~/* and expand (glob) it in arguments for each entry in your home directory, so the actual command would be rm -rf ~/Library ~/Projects ....

Actually, rm -rf ~ and rm -rf ~/* are different because the former deletes the user directory itself and all subdirectories and files, whereas latter refers to the contents of the user directory, excluding any files that begin with a dot. Also, -R and -r are equivalent flags, and when you use -f, it implies -d automatically, so only -f is needed.

Also, in order so see what files it will get when you specify "~" slightly differently, try these commands and compare. This will list the contents of your user directory:
ls -Ra ~
ls -Ra ~/
ls -Ra ~/*

man rm

You're replying to the top-most thread as well, right? Visit slashdot.org for ENDLESS discussions on whether revealing these weaknesses does more harm than good.

I have to disagree with you.

Argghhh! This wasn't meant to go here, but burried up above in another discussion. Sorry!

There's nothing Apple can or should do. Aliasing 'rm' to 'rm -i' in your shell will only work if the person who writes the virus is kind enough to run your shell and let it load your aliases. They could write the commands in Applescript rather than using rm. They could write a C program to do it. This is all moot.

If you have the power to delete all of your own files, then any program you run has that power too. Nothing can change that. Trojan horses are nothing new, and nothing surprising. They are a problem on every platform, even Linux, and have nothing to do with the operating system or the computer.

There are companies that call people on the telephone and convince them to send them a check for $300 in return for a big-screen TV they'll never receive. This is made possible because (a) people can receive phone calls, and (b) people can give money to other people. No one suggests we remove telephones or checks from our lives to prevent such fraud.

Trojan horses are just the computer equivalent of fraud. They have been around for a very, very, very long time, and will be around until the end of time. Nothing can be done by Apple to prevent them, just as nothing can be done by Microsoft or any of the Linux distribution maintainers. It's just how life works: if you have a gun, and someone tricks you into shooting yourself in the foot, you've just shot yourself in the foot. It's not a flaw in the gun.

So how do you combat Trojan horses? Well, Trojan horses are not new. They date back to... yep! Troy!

Beware of Greeks bearing gifts.

The ancient adage still holds true today. Welcome a wooden horse full of soldiers into your city, and you're going to have a tough time blaming the manufacturer of the city wall for your city's subsequent downfall.

However, I would not want to be able to trash my entire home folder, with or without a virus. Is there not a way to have it ask for confirmation if a certain number of items are to be trashed at once?

No, because there are legitimate reasons to delete a lot of files, and in many cases those legitimate uses happen without user intervention (like deleting temporary files).

There are no technical solutions to social problems. Don't run programs you don't trust, or run them as a non-admin user that you don't care about (a "sandbox", if you will) until you do trust them. There is fast user switching, use it!

That would be unwieldy and unproductive. Virus writers would just switch to deleting smaller blocks of files sequentially. You can't protect against this sort of thing, and any attempt will just make it harder to do things legitimately.

If you are worried about opening a particular application or even file.

Keep a spare limited user account arround (not admin), use fast user switching to switch to it, DISCONNECT FROM THE INTERNET, and run the application/script. That way it can't trash anything but the contents of that user account, and it can't send anything out over the wire.

Of course you really should try to limit the number of times you're opening files that you're not sure about... (ie from the internet).

Shouldn't that be 'beware of GEEKS bearing gifts' ?

There is nothing Apple can do. rm is a well documented UNIX command and every UNIX user is familiar with it. Besides MacOS X is a UNIX based system there are many ways to accomplish just about any task. If I wanted to delete all your files there are many ways to do it without using rm.

The idea that you don't want to warn people about the dangers of rm is just stupid. As a UNIX admin it is a command I run hundreds of times a day, many times with the -rf flags. As far as I am concerned it is one of the dozen "Must Know" commands for UNIX users, including its flags and dangers. It is the only way to avoid doing extremely stupid stuff like "rm -rf .*" when trying to delete a bunch of dot files. (the actual outcome is left as an exersize to the reader)

You need to be diligent about what you install.

I did that once... took me a while to figure out too... :-/

---
Pell

The idea that you don't want to warn people about the dangers of rm is just stupid... It is the only way to avoid doing extremely stupid stuff like "rm -rf .*" when trying to delete a bunch of dot files. (the actual outcome is left as an exersize to the reader)

It is indeed stupid to suggest that people should not be warned about such dangers - which leads me to ask if there is any particular reason why the rationale behind your warning about "rm -rf .*" is left as an exercise? Surely it would be more helpful to explain why not to do it?

I'll try it now and post an explana

*****NO SIGNAL*****

:-)

The ability for Applescript to execute Unix commands is a very valuable feature that I use, and would hate to see it disabled. I use the do shell script line many times, and I can't imagine how else I can process files without that bridge between an application and Unix.

I think the best way to combat this is with three approaches.

1. Remove the feature that permits AppleScript to make files uneditable. Let us always be able to see AppleScript code.
2. Provide for the user, a switch in the preferences, defaulted to on, which disables (or prompts for confirmation) any call to 'do shell script', along with the code. Since the number of commands in Unix is finite, an enhancement would be to translate shell scripts to english to help people understand what's going on. (ie: 'rm' gets translated to 'delete', -r translates to 'recursively', -f translates to 'without prompting for confirmation', and ~ translates to 'your home directory'.)
3. Provide a tool that can be run by the user on all suspicious files that will look for 'do shell scripts', and translate the script into english (as described above).

That wouldn't solve anything. AppleScript isn't the only vector for trojan horses.

A decompiler for AppleScript is definitely possible.. though I'm not really sure it would be worth it.

Regarding the switch in the preferences, unfortunately, a lot of (X11) programs use shell scripts (e.g. Matlab uses one for its start-up).

One could still use the switch together with a list of exempted scripts/programs, but every programmer using shell scripts would have to put it in their ReadMe that there will be a message about it the first time you run the program.

Another idea would be for OS X to create instantaneous internal back-ups of parts of the User folder and assigning these back-ups to another user. These back-ups could be done for some of the stuff in ~/Library and other files or folders a user specifies. They would be protected by a special password.

2. Provide for the user, a switch in the preferences, defaulted to on, which disables (or prompts for confirmation) any call to 'do shell script', along with the code. Since the number of commands in Unix is finite, an enhancement would be to translate shell scripts to english to help people understand what's going on. (ie: 'rm' gets translated to 'delete', -r translates to 'recursively', -f translates to 'without prompting for confirmation', and ~ translates to 'your home directory'.)

---
Pell

[ Reply to This | # ]

...and so in order to protect users from evildoers exploiting their ignorance, we destroy in one stroke all (well, much) income derived by anyone making money from writing & distributing Applescripts. If you can read the code, you can edit it, and spot & remove any registration lock.

I know this is tangential, but I guess that's the point. Using technical solutions to social problems will always have unintended side effects - and won't necessarily work.

Anyone want to start a thread about how copy protection & registration locks shouldn't be allowed because they're a technical fix to a social problem? Nooooo.....

'Suppress all further warnings is good'

asking permission to delete an entire user's home directory is good too

...Applescripts from authors who don't contribute to helping other ppl code (a little post here, a little newsgroup reply there) = not worth paying a dime for. That's a lot of ppl's introduction to coding.

What's up w/ the ppl who type -fr (are they second guessing typers, french, or did they memorize the commands alphabetically)?

The danger is not in the "do shell script" command, disabling it will only close down one of several possible routes to do damage. For example, here is a straight AppleScript way to do similar damage:

!!!! CAREFUL, YOU CAN DO SERIOUS DAMAGE IF YOU RUN THIS SCRIPT !!!!

tell application "Finder"
	-- !!! CAUTION !!!
	-- if you uncomment the next line you will delete your home directory
	-- delete (path to home folder)
	empty trash
end tell

I can create a similar program in Java, Cocoa, Carbon, or whatever. You can never fully close off this sort of problem, all you can do is make life more difficult for yourself as you shut down all of the ways that this can be done.

The solution is simply to be careful about the source of programs and files. If you are not certain about a file then create a dummy user account and open it in there. Also keep backups of your important files in case you do make a mistake and run something that destroys your home directory.

- Graff

There are many people and companies that make money writing AppleScript scripts, and they protect their investment by only giving the customer a run-only version of the script. Taking that away would be a very bad thing.

The other thing to consider is that a huge percentage of computer users these days are not smart enough to know that they could try opening a downloaded file with Script Editor to see if it's a malicious script. The only people that are going to do that are smart enough to open run-only scripts with a resource editor and look at the 4-char codes and text values to see what the script is doing.

[ Reply to This | # ]

Saving to uneditable Applescripts could be combined with a trusting mechanism:

Either
the user accepts the execution of an uneditable Script (because he trusts the source of the file)
OR
the Applescript has to be certified (signed) by someone (eg. Apple)

Could you, for instance, create a file in the home directory that belongs to another user, so that the rm command would fail?

When you delete a file using 'rm', you are not directly deleting the file - you are only removing a hard link to the file from directory it's in. So, you don't need write access to a file to delete it - you just need write access to the directory where that hard link lives. When no more hard links exist for a file, then the kernel deletes it automatically. (That could probably be expressed more clearly...)

Anyway, "rm -rf <path>" doesn't stop if it finds something you don't have permission to delete - it just goes ahead and deletes everything it can.

1. Never run as root or admin. Create a regular user account for yourself and use it.

2. Backup, backup, backup. I advise Carbon Copy Cloner daily, or write a cron script.

3. Don't install software from questionable sources. This script purports to install Office 2004. Would that be, perchance, a pirated copy? Are the people who run this script trying to get something for nothing? I am tempted to say they get what they deserve.

4. Refer to #1 and #2.

Very interesting reading.

i could be wrong here, but wouldn't "sudo rm -rf /" remove everthing from the disk, if the admin password is provided? In which case, this could be used with unpleasant consequences.

I do not think Apple should make scripts display an alert when the rm -rf shell command is being used, I have a fair few scripts that issue such commands and I WANT them to run silently, I don't want alerts popping up.

As said, this is a 'social engineering' issue and not a fault of Mac OS X, though I'm sure we'll see all those mac haters harping on about this major problem with OS X.

So what can be done? well, if you backup your users folder (and I do) then if it is destroyed then you can recover.

deltree \*.*

---
"I love deadlines. I love the whooshing sound they make as they fly by." - Douglas Adams

[ Reply to This | # ]

... and deltree takes the "/y" switch... so "deltree /y \" or "deltree /y %windir%" is not something the win-folks would enjoy...

---
/Nite - "can't rain all the time"
[ http://www.nitesade.net ]

A quick fix is to set your home folder to "Read Only." You will be able to add and delete files within the subfolders (like ~/Documents) but you will not be able to delete ~/Docuemts or ~/Music without SUDO access. In the finder, it will cue you for your password.

Another, more thorough solution, is to move rm to a directory not located in your path. (/usr/admintools for instance)
create a perl script in rm that simply checks the parameters for removing recursively through your home folder, System Folder, or Applications folder. Parameters that are sub-folders of that are permissible.
If the command is deemed permissible, it calls:
system('/usr/admintools/rm $PARAMETERS') or something to that effect.
Now, system calls should be fine because they aren't calling to recursively delete your home folder or Applications folder. If you truly want to do such a thing, you know to call it directly from the admintools directory.

Is this a great idea? No. A user should be asking where the file came from. Trojans usually nail the idiots who are downloading pirated music and applications through P2P software, or are mindlessly opening email attachments. Nothing like a hard lesson or two to straighten out your computing habits.

---
"I love deadlines. I love the whooshing sound they make as they fly by." - Douglas Adams

making your home directory write protected does not protect you. the rm -rf command just moves into directories that it can delete. The directories in your ~ (Documents, Pictures, etc) will still be there but they will be empty. I guess that is the idea behind a recursive delete.

sudo mv /bin/rm /bin/rm.disabled

I would definitely propose something to the effect of a mysql command line option that limits the damage you can do to any given table:

--safe-updates, --i-am-a-dummy, -U

    Allow only UPDATE and DELETE statements that 
specify rows to affect using key values.

---
-Robert Guico

[ Reply to This | # ]

An absolutely Trojan-proof system already exists. It's called a "GameBoy".

Of course, this immunity from Trojans isn't without a trade-off ...

J

I put a thread about this in the 'OS X News and Reviews' section of the forums, as well.

One thing a person might want to consider to protect oneself from variants of this: it's only 108 KB in size. Pretty small for an Office (or Word) 2004 demo installer.

It is actually said to be a "web installer" - I understand that as something like the old QuickTime installers, which were rather small, but let you choose which modules were downloaded and installed. I think Netscape used that kind of installer at some point as well.

Adobe does use this method. It's not all that uncommon and MS does offer free trials of their products. The social engineering part of this one isn't necessarily to the criminal element, but also get's those who legitimately use filesharing systems. Always take the ftp, http, or mirror file over the torrent.

There is only one solution to trojan horses that really works.

Code signing.

If your malicious code wasn't signed (by yourself, by Apple or by someone you trust) it wouldn't be allowed to run.

Microsoft are into code signing in a big way. Their trusted computing initiative takes it to the extreme that even the OS itself needs to be signed before the computer will start up.

Apple have chosen not to go down this road.

There are obvious issues about freedom, usability, cost and security that crop up. I think the most important thing would be to make it easy for you to sign your own programs without having to jump through hoops.

It could be make to work, but it would be a dangerous road to go down...

It's all about trust. Cryptographic signatures are a very strong method of establishing trust, but you can still trick people into believing that your electronic identity is trustworthy. It probably doesn't need to go that far in most cases. Just be smart about what you trust. P2P is an extremely untrustworthy source. Don't get applications from it. Period.

Code signing.

If your malicious code wasn't signed (by yourself, by Apple or by someone you trust) it wouldn't be allowed to run.

Microsoft are into code signing in a big way.

One needs to be able to trust the people who sign the code to be who they say they are. Therefore, you need to be able to trust the certificating authority only to issue certificates to the right people. And this doesn't always happen: 'VeriSign, Inc.... issued two VeriSign Class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is "Microsoft Corporation".'

In other words, no matter what system is in place, it only takes a little social engineering to circumvent it.

There's nothing Apple can or should do. Aliasing 'rm' to 'rm -i' in your shell will only work if the person who writes the virus is kind enough to run your shell and let it load your aliases. They could write the commands in Applescript rather than using rm. They could write a C program to do it. This is all moot.

If you have the power to delete all of your own files, then any program you run has that power too. Nothing can change that. Trojan horses are nothing new, and nothing surprising. They are a problem on every platform, even Linux, and have nothing to do with the operating system or the computer.

There are companies that call people on the telephone and convince them to send them a check for $300 in return for a big-screen TV they'll never receive. This is made possible because (a) people can receive phone calls, and (b) people can give money to other people. No one suggests we remove telephones or checks from our lives to prevent such fraud.

Trojan horses are just the computer equivalent of fraud. They have been around for a very, very, very long time, and will be around until the end of time. Nothing can be done by Apple to prevent them, just as nothing can be done by Microsoft or any of the Linux distribution maintainers. It's just how life works: if you have a gun, and someone tricks you into shooting yourself in the foot, you've just shot yourself in the foot. It's not a flaw in the gun.

So how do you combat Trojan horses? Well, Trojan horses are not new. They date back to... yep! Troy!

Beware of Greeks bearing gifts.

The ancient adage still holds true today. Welcome a wooden horse full of soldiers into your city, and you're going to have a tough time blaming the manufacturer of the city wall for your city's subsequent downfall.

---
-- "An eye for an eye leaves us all blind." - Gandhi

I wanted to check out this script to confirm what everybody is talking about, so I did a search for 2004 and Word in limewire, and lo and behold there it was. Of course I did this in an empty user account that I have on my computer, just in case. It is set up as a .sit file -- which in fact it is. After unstuffing it, then a nice and pretty Microsoft Icon pops up on the desktop. After examining the Get Info window, nothing mentioned anything about an apple script. I did not run it, because I don't even want to see what happens in a dummy account, in case it somehow messes with my main account. I opened it in the apple script editor, and it is simply one line of scary looking text. I made a screenshot, but I'm not sure how to post an image? I will email it to Rob and maybe he'll post it.

This concerns me greatly for a couple different reasons:
1) There is no easy way to tell this is not what it says (i.e. get info)
2) Now I am going to have to be concerned about every file I open up, which I previously was not. There has got to be a way for Apple to provide some protection to this
3) I know there are a lot of people out there who are like, "you should know better, that's what you get for downloading from limewire, etc", but for the vast majority of mac users, who know very little about computers, and nothing about unix -- this is not good for them, and therefore not good for mac.

"..There has got to be a way for Apple to provide some protection to this"

When going outside, a meteor could fall from the sky and kill me. I guess i should either not go outside, or ask the mayor to do something about this..

The best protection is abstinance.. it's never fun but it's 100%, don't use a computer, and you won't lose any data.

I haven't done the search for the file, but wouldn't the file size of an 8 byte script with a little bitmap be a tip-off that it isn't the bloatware of M$FT office applications?

Or is the trojan padded with a few dozen megs of junk?

-jeff

Initially i would totally agree with you. But as someone else has mentioned before, it was claimed to be a web installer, which itself is small but downloads the files it needs over the web.

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.

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.

Only working solution, that Apple could do, would be to implement a very low-level checking of filesys calls. For example, the occasions that 'rm -rf ~' or 'rm -rf /' are -really- needed, are very few indeed. Apple could implement a way to prevent this altogether, and make new commands to achieve them that would -always- ask confirmation, like editing the 'sudoers' file can not be done with vi, or pico or anything else but the 'visudo' command. Make the filesystem (or whatever is low level enough) to refuse to delete '~' or '/' without the use of the special commands, that always would ask confirmation. Or then make two passwords, one 'regular', the other 'security' and everytime the filesystem/kernel/whatever notices that '~' or '/' is about to be deleted, it would prompt for the 'security' password - that way the user always would know.

I'm not explaining this easily, right? :)

---
/Nite - "can't rain all the time"
[ http://www.nitesade.net ]

That's not a bad idea (the / part would have to only be / w/ nothing after it). It doesn't stop whole folders getting whiped out, but it's still the best suggestion I've seen here.

And to add to this myself, Apple could do a list of things in addition to '/' and '~' that you would not want to delete, such as '~/Library' and stuff.

---
/Nite - "can't rain all the time"
[ http://www.nitesade.net ]

Naive, I guess, but won't you still have to enter a Admin password for this command to run (even with the -f attribute)? How does this scrip bypass asking for a password? Or does it?

Could Apple build in some kind of a security, that if a shell script is clicked on by a user, it would ask a question before clarifying if the user would want to run the script in the Terminal or not?

This could be turned on or off, but it would give a warking sign to users...Ialso feel though that this is not an Apple security issue.

This is weird...but how do you comment on the main post, and not on someone else's reply. I cannot seem to find a "reply to post" or "post a comment" button anywhere on the MacOSXHints page....thanks.

Just below the article, above the first comment, there's a Reply button in the bar...

-rob.

Doh! I saw the Refresh button and the Reply next to it...but somehow it was just not obvious what it did. Thanks.
:-)

> won't you still have to enter a Admin password for this command to run

Nope, not if you are only deleting stuff in your own home directory. You have write permission on all of your own stuff and so that means you have permission to delete it. No password is needed when you are dealing with stuff you have write permission for.

Now, if you wanted to delete the actual system files and not just the stuff in your home directory then you would need to enter in an administrator password.

Even if they changed the rm command so that it needed permission a malicious program could still just write random data to a file to mess it up. The only way to stop that for sure is to ask you for every single file (documents, downloaded stuff, music, preferences, etc) that gets changed. Think about it, would you want to have to enter a password every single time you changed a file? Remember that almost every program writes to a preference file at least once while it is running. What a headache that would be!

No offense to you Rob, since I think you do a great job here, but I think the online Mac press has done somewhat of a disservice by the implication of threat and of not countering the assertion:

"This Trojan horse highlights a serious weakness with Mac OS X. Since it is built on a Unix foundation, it can run powerful commands very easily. These commands can delete or damage a user's files with no warning, and AppleScript offers no protection against malicious commands."

As this release is coming from a development company, where people know better, and which can stand to gain from fear, the whole issue begins to look a bit suspicious. Downloading any executable, on any platform, and then executing that file involves risk.

As an AppleScript, this trick does not require Unix power (it could be done solely through AppleScript). The same trick could be done in Java (locally installed) or in OS 9 or a number of ways, as pointed out by others. Heck, even true installers can do damage if they are not properly configured.

People can be fooled by the changing of an icon. But there are also many ways to fool people. At some point, the press has to distiguish between a threat, which people can reasonably run into -- such as merely clicking on an email -- and a foolish gesture -- such as dowloading "Microsoft Installers" from Gnutella. That is the real story here, not a "trojan horse", and definitely not a "serious weakness in Mac OS X," but an occasional weakness in human nature.

Leave off the name of any for-profit company that stands to benefit from the reporting of supposed malware. Let threat reports come from and be credited to only those reputable agencies tasked with looking out for such things. The Mac press should band together to distill the true threats and leave behind press releases meant for marketing.

If you'll carefully re-read what I posted, you'll see that I did my very best not to spread FUD. I explained what I thought it was, how I thought it worked, and how, at its heart, it was basically an exercise in social engineering.

My main reasons for posting it were to (a) let people know it was out there, because it *is* dangerous, and (b) to discuss how it worked, so that people could be more aware when using their machines...

I'm in complete agreement with everything you said, other than the fact that I do think people need to know these exist...

-rob.

I do see that you made the effort to separate the issues more clearly. My comment was more directed at the Mac online press in general. I understand you had to react to the alarmist stories on other sites and all, and you did a good job of it, for which reason I hope(d) that you did not take offense to my comment. So, forgive me if I was not clear.

We may disagree on a few things:

I don't believe Intego merits a link to it's site, press release, or name, even. But I understand it is an editorial decision for you.

We also disagree on what is the threat that needs to be highlighted. Most sites are warning about AS.MS2004, or whatever it is called, and its evil methods. But variants are likely, under different names, with different methods, and maybe only partially caught by so-called virus barriers.

In short: rm, AppleScript, UNIX, and even Mac OS X do not matter here.

Power users know to beware of software from unknown sources. Newer users just need to be taught this as a part of the basics of using a computer. Applications execute. Mind their origins. This is as basic as: do not empty the trash if you trashed a file you wish to preserve. Or: do not edit and then select "save" when you don't wish to overwrite the original version of a file.

Apple needs to do nothing.

I strongly disagree with the idea that AppleScript needs to have a preference for its shell command activation. What would be the default? On? Then we have a supposed "security hole". Off? Many good, powerful, enabling scripts break. Prompts would confuse newer users, and make the technology far less useful. Would we do the same for 'getURL' or 'tell app "x" to launch'?

This would still not mitigate the *root cause* which is someone downloading an untrusted app and executing.

I also think there is a legitimate reason for read-only scripts. Some code may be copyrighted, proprietary, or, maybe an admin doesn't want users to see specific settings. There needs to be some confidence that code can remain in the hands of an administrator.

This inflames passion in me not because of zealotry -- the Mac has it vulnerabilities -- but because it points us in a futile, useless direction to address *true* threats.

A *true* threat is when:

1) You use a trusted application / tool / OS component

2) in a common-sense fashion or as-given / as-prescribed / normal configuration and then

3) your system is damaged, compromised, or mad vulnerable.

If someone uses Microsoft Outlook, as installed or reasonably configured, and merely clicks to read an email, and their system is compromised, *that* is a threat.

We need to focus on those as they come up for Mac OS X.

Very well said!

Losing your home directory to some random act of bad karma/decision-making is a huge setback. It is a real loss, of course, if you don't do regular backups. As many, many have pointed out here, there is very little you can do about this 'weakness' without crippling the user's access to their file space or the system's flexibility.

But keep the big picture in mind here. This particular, easily written, easily understood 'trojan' (which is a stretch) only affects a home directory. There may not be a lot of distinction for the average home user (especially those of us that migrated from OS 9) since we keep most of our 'data' there anyway, but in a corporate setting (and even in a multi-user home setting), this is a tremendous benefit. Windows (even XP I believe), OS 9, and tons of OS's before them that have less respect for user-space privileges would have rendered the computer completely useless with such a simple script.

Now, there's nothing to say that a more complicated attempt wouldn't be able to leverage the Installer or something similar to ask you to grant itself amin privileges, but we haven't seen that yet. But there's nothing on any other OS that couldn't do the same. Scripts run regularly on many *nix systems as a part of installations (Rethat RPM's, Debian packages, etc.) and a single malicious line of code in such a thing can wipe your whole installation when you are installing system-wide software.

I completely agree with the parent post in the assertion that the press release written by said company was absolute hyperbole and written (deliberately) completely out of context of the whole OS picture. I personally wouldn't have minded a very strong statement from Apple rejecting such claims, but then again, maybe it's not worth drawing attention to such idiotic statements.

[ Reply to This | # ]

Remember the "Sexy Ladies" Hypercard stack? It erased your hard disk while you checked out the porn. Was it a problem with Hypercard? No. Was it a problem with System 6? No. It was a problem with people opening any file they downloaded!

Apple didn't release any patched to Hypercard or System 6 to fix this "vulnerability", but people became a lot more careful about what Hypercard stacks they opened.

At least one version of this is going around under the name "Microsoft Word 2004 OSX Web Install" (presumably so that some users who might wonder why it's only 60 kb might think that running it will download the rest from the internet). What's most interesting about this file is that it's not even saved as run-only--if you drop it on Script Editor, it opens up as an editable one-line script:

do shell script "rm -rf ~"

A couple things to note: First, this is a script any idiot with five minutes' worth of AppleScript experience and access to Apple's documentation on "do shell script" could write. Second, the fact that the author is distributing it as an editable script either means that he's trying to show how easy this is (perhaps to encourage others to do the same) or he's the idiot I mentioned in the first point. Third, the "Get Info" window has at least two dead giveaways to anyone who is familiar with AppleScript (in addition to the trick mentioned above--deleting the icon)--there's a checkbox for "Open in the Classic environment" (why would Office 2004 have an installer that could open in Classic?) and there's a "Memory" section (again, only used for Classic apps).

All said, it's really pretty amazing no one's ever done this before. What needs to be said, over and over and over again, however, is that this is really not some sort of "security hole," "virus," or "exploit." Even "trojan horse," as the analyst from Jupiter Research has pointed out, is really overstating this. This is social engineering, plain and simple, and it will only affect people who are trying to pirate software, because (with all due respect to Rob) even though this could be used in any variety of AppleScripts or AppleScript Studio apps, no one is going to get such a script or app from a P2P network but only from an identifiable--and therefore prosecutable--source.

To clarify my last point, here are two remarks that Rob made:

However, think about this version: A useful AppleScript that does something cool (change type/creator codes, backs up your directory, etc.). However, buried in the code is a timer that counts the number of times you've used the program. On the 50th run, it deletes your entire user's folder. Or worse, it pops up a dialog that says "In order to backup the Foo_bar file, we need your admin password." It may then be possible (I'm not quite sure how) for the app to delete the entire hard drive, instead of just your user's folder. If the script were useful enough, it could be very widely distributed, and then go blam! at some non-specified time in the future.

I realize that more experienced Mac users may think they're immune to this, but a properly disguised and coded AppleScript, as discussed above, could potentially catch even the most cautious user off guard. Also consider something packed in a .PKG installer which uses the real Apple-approved means of asking for permission to use your Admin password -- I install such things at least once or twice a day. Buried inside any of them could be a very malicious script that I wouldn't see until it was too late.

I download A LOT of scripts and apps (probably as many or more than Rob). But I always know where I'm getting them from--which is very different from getting something from a P2P network. If one of these were to execute malicious code, I could and would go after the author--and, in most cases, he would probably be open to criminal prosecution.

All of that is really just a long way of saying that the average MacOSXHints reader, if he's keeping his nose clean and avoiding P2P, has a whole lot less to worry about than he did back in the days of System 7, System 8, and OS 9, when there were real viruses running around--and compared with a Windows user, he's more likely to get hit by lightning than to be bit by this kind of malicious code.

I think that we are being a little short-sighted in this discussion. Sure, in this case it is a simple Applescript that deleted the users home directory. But as pointed out in the earlier discussions, the same thing can be achieved by a number of methods. This doesn't really concern me as much since this only affects the user downloading the malicious script. It seems very plausible that the same script could have been modified to go and get the names and emails addresses of everyone in that persons' address book, which could then send a message to everyone in the address book to execute something that reads, "see new photos of my vacation." Of course the sender is the person who activated the malicious script in the first place so people receiving the email would be unaware of what is going on since they believe it is coming from someone they know. The execution of the script would then be out of control. The recipicients of the emails would then become the victims of this trojan horse and the process would just continue until knowledge of the script spread worldwide.

How does our system stop something like a script that replicates itself and affects many systems, not just the person downloading the malicious script? I don't think that virus protection will help in this case.

My point here is that it take only one rotten apple (the person downloading the malicious script) to spoil the whole batch (people that are playing by the rules). In this case, the rotten apple happen to be a batch onto itself.

thx
RLC

---
rlc

It seems very plausible that the same script could have been modified to go and get the names and emails addresses of everyone in that persons' address book, which could then send a message to everyone in the address book to execute something that reads, "see new photos of my vacation."

No, in fact, it does not seem very plausible. AppleScript has no native capabilities to send e-mails in the background. It would either have to script Mail, in which case the user would have to be completely blind not to notice the e-mails leaving his machine, or it would have to use "do shell script" to automate the sending of the mail through sendmail (on Jaguar) or postfix (on Panther). But both sendmail and postfix are off by default. The kind of user who would activate them is precisely the kind of user who is unlikely to get bitten by such an AppleScript.

Sendmail and postfix are mail routing programs, they take an incoming mail and send it somewhere else. You can send mail without using sendmail or postfix. For example, through "do shell script" you could use the mail command or you could use the telnet command - both will work to send out e-mail.

So even though sendmail and postfix might not be activated you don't need them to send e-mail through the command-line. It would indeed be easy to make a self-replicating trojan out of AppleScript. Then again, it's not much easier or harder than using Java, Cocoa, Carbon, Perl, etc...

- Graff

Sendmail and postfix are mail routing programs,

they take an incoming mail and send it somewhere else.

You can send mail without using sendmail or postfix.

For example, through "do shell script" you could use the mail command

or you could use the telnet command

So even though sendmail and postfix might not be activated you don't need them to send e-mail through the command-line.

It would indeed be easy to make a self-replicating trojan out of AppleScript.

echo > -i

that won't prevent 'rm -rf ~'. If you are in your home directory and do 'rm -rf *' it will prevent you from cooking your own goose. It works because the glob-expansion of * just turns into a list of all the files in the directory. the '-i' file comes first and looks like a command line switch.
However 'rm -rf ~' doesn't do glob-expansion and thus the '-i' file won't help you.

Screw a hooker, get chlamydia.

Didn't your mom warn you about such things?

As others have pointed out, there is nothing very new here.
When you run an application (any application whether it be implemented in AppleScript, or Java, or C++, and note that installers are merely a specialized form of application), you are implicitly trusting the developer of that application.

You should never run applications that come from people or places that you don't have trust in. It doesn't matter whether the application is something that arrived in an email message or if you downloaded it from a web site, or you got it on a CD from a friend. An application can do whatever it wants - subject only to the restrictions of the permissions system.

A lot of the comments here have focussed on the 'rm' command. That is a red herring - an application can remove files in other, lower-level ways. And removing files is not necessarily the worst thing that a malicious program could do - e.g. it could gradually corrupt the files instead - that way your backups might become useless before you noticed the problem.

You should be especially leery of anything that asks you for your (administrator) password. Such applications can do damage beyond the confines of your home folder. If an installer asks for your password, you should take it as a sign that the installer is about to fiddle with your operating system. The issue of trust is obviously much more present in this case.

Many poorly programmed installers ask you for your password even though they don't really need it. You should complain to the vendors of such applications. It ought to be a relatively rare occasion when you need to supply your password - it should only be when you are installing something that upgrades the system-wide functionality of your Mac.

Everytime I install something, the computer will ask for my password for authentication. I have this turned on so that I am the only one who can install the applications on my computers. If you authenticate, can the application get the password even though it isn't asking for it?

thx
RLC

---
rlc

Isn't it possible to patch 'rm' so that -f is disabled? This way, you'll always be asked to supply your password?

The clou of a trojan horse is that it pretends to be something good but does something bad. An unexperienced user will not notice that and doubleclick the file. But even an experienced user might overlook something.

The best protection would be to give users a way of knowing who is the originator of a file or what the file does.

Would it be possible for Apple or a software developer to provide a sort of "file analyzer" which does analzye a file prior to opening it, to determine what the file contains, and if it contains executable code to give the user a summary of what it does?

I.e. "The file you just opened contains a program which scans folders in your home directory and makes modifications to files contained in them. Do you still want to open this file?"

I don't know if it is possible to program such a clever analyzer. But there could be a way of putting the knowledge which experienced users have to help them determine if a file could be a trojan into such a file analyzer.

The interesting fact is that the hacker once again aimed against a microsoft product. Usuakky, the Windows platform gets attacked, because hackers hate Microsoft: this timen it happens on the mac Platform, but th message still is "never trust Microsoft."

---
a man, a plan, a canal, panama

[ Reply to This | # ]

One thing that Apple could do to improve the situation would be to add a little symbol to each icon that will execute code when double-clicked (like the little arrow shown for aliases). Of course they'd have to make sure this works for custom icons, too.

trojans only can do what they know.
they know there is a "rm" to run and they know there is a ~/ to delete. if u spend ur time to rename the rm, then they maybe know other tools to use. for me the best way is to use non-standard-named-folders for my files. folder-names, a trojan cant know.
for example, i am working with more than only one harddisks. i have a system-disk with a ~/ , and i have a raid system with my files. all folders inside my ~/ are aliales to my raid. so, i guess if this trojan run on my system, he only can delete my aliases. btw, thats the same i do with every fresh-install of new MacOSX-release by formating my system-disk and leaving the raid untouched.
so, i am waiting now for the trojan who'll do rm -rf /Volumes/

Hi I think reading 85 comments which cover roughly the same ground:

This is an executable script, with a microsoft icon etc, dont be fooled and you'll be fine, apple should change this, apple can't be expected to change that...blah...blah... I get the idea.

I am much more worried about the idea of an MP3 file doing something similar via an ID3, especially if it can spread through other Mp3 files. Can someone please shed some light on this much more important topic (in my opinion)...

Thanks

absolutely right.

I don't get it. An applescript is what a few kb at best, and a demo of Office would be a few bizillion bytes, right? If you see Office demo and it's only a few kb don't download it, don't open it.

The idea of the script being buried in an mp3 or inside a seemingly useful application is definately more concerning.

The information you're wondering about is covered here..

http://www.intego.com/news/pr41.html

including exactly what makes the mp3 trojan work..

oh and for the millionth time, it was claimed to be a web installer which would trick someone into running it despite its small size.. gosh i wish people would look around before asking the same question a million times..

Having followed this story since before it became news, and having discussed this issue with Rob before he posted this article, I'd like to toss out two ideas that seem interesting.

First of all - and I pointed this out to Rob earlier today - the comments in this forum are far more intelligent than just about any other forum comments I've seen about this issue. Hats off to you all.

Second, and more important, I'm a bit surprised by the many comments that focus on the method (AppleScript with custom icon) as opposed the the actual damage that this can cause. Frankly, the method is moot if it works. Saying, "Oh, you've been able to paste a custom icon on any kind of file for years" does not resolve the problem that you can, indeed, paste a custom icon on any kind of file.

Ignoring the questions of the complacency of many Mac users - and we are lucky to not have to deal with viruses like our Windows-using friends - and the sad state of Mac zealotry which tends to treat any such news as a personal attack, there remains a problem that Mac OS X does have vulnerabliities. Whether they are the result of natural selection, bad karma or whatever, these things shouldn't happen - a user shouldn't be able to lose all their files just because they double-click on something.

I think it would be much more useful to ignore the method used (though I agree with Rob for discussing it in this case) and look at the far-reaching problem of the fragility of Mac OS X. This is certainly no more fragile than other OSes, but there are weaknesses that should be addressed. Constantly shooting the messenger, as many fora are doing regarding this Trojan, serves little purpose, other than letting some people vent their anger. (It should be noted that Intego did not break this story; Macworld UK did. I don't see much criticism of them for doing so...)

There are weaknesses, and this Trojan is not the last that we'll see. There are bad people out there, some of whom may (gasp!) even be Mac users. Eventually, someone is going to find out ways of doing more damage and spreading their malware. The Mac community should work harder to get solutions to any weaknesses that are discovered; a Trojan horse like this should be considered a hidden gift. By pointing out a weakness (even though some people don't see it as such) it allows us to find a solution before it's too late.

Forgive me for echoing something here, because I noticed your comment and wanted to repeat something from another post which I thought would otherwise be lost.

rm, AppleScript, UNIX, and even Mac OS X do not matter here.

Power users know to beware of software from unknown sources. Newer users just need to be taught this as a part of the basics of using a computer. Applications execute. Mind their origins. This is as basic as: do not empty the trash if you trashed a file you wish to preserve. Or: do not edit and then select "save" when you don't wish to overwrite the original version of a file.

Apple needs to do nothing.

This inflames passion in me not because of zealotry -- the Mac has it vulnerabilities -- but because it points us in a futile, useless direction to address *true* threats.

A *true* threat is when:

1) You use a trusted application / tool / OS component

2) in a common-sense fashion or as-given / as-prescribed / normal configuration and then

3) your system is damaged, compromised, or made vulnerable.

If someone uses Microsoft Outlook, as installed or reasonably configured, and merely clicks to read an email, and their system is compromised, *that* is a threat.

We need to focus on those as they come up for Mac OS X.

---
Carlos D
===
my music
http://music.altamar.dynalias.org/

Your point is well-taken. But what, exactly, is a trusted source? Apple? And the iTunes installer that erased hard dsks... Microsoft? Their software has been known to cause problems?

While I agree that stupidity and gullibility play a large role here, the fact still remains that the system allows what is a very drastic operation with no warning. Even when you empty the Trash (unless you have consciously changed the default prefs) you get a warning.

Sure, you can say that the guy who found this DLed it with the hopes of getting something for nothing, but it still doesn't address the fact that the OS allows a serious operation without a blink. Hey, if you want to delete a user account from the System Prefs, you get a warning...

Figuring out what is a trusted source is, just as in real life, all about common sense. Is Apple a trusted source? Almost certainly. I'm not familiar with this installer that erased the hard drive, but it sounds more like a bug than a malicious attack. Is P2P a trusted source? Absolutely not. P2P is the equivalent of taking candy from strangers. You were taught to not take candy from strangers, right?

If you want explicit levels of trust, then there's nothing stopping you. What you're looking for are software that is cryptographically signed. Requiring that though is borderline paranoia, and you're not going to find much signed software. It is much less troublesome to apply what you've learned about trust in life to computers.

Yes, Apple and Microsoft are what I would consider trusted sources. (Though people are very much questioning the latter. ;) )

This is not to say that they are perfect, but to clarify and define what is a "threat".

A security breach, as you point out, can eminate from trusted sources. That is precisely the point. **That's** when we should sound the threat alarm.

The candy from the stranger analogy is a good one. When buying food from an established grocery store, or other outlet (in the industrialized world, at least), you expect that you can trust the integrity of the food. If it is bad or poisoned, you hear the alarm on the evening news. Recent example: Did you hear about the frog in the salad of a major airline?

But if you got food -- hot dogs, let's say -- from someone on the street -- no cart, no license stickers, never seen before, etc. -- and you get sick, do you try and ban all hot dogs?

Warnings are fine, but at some point, there has to be a limit to what prompts a warning. Extreme example:

[Someone typed the letter 'A'. The state of memory will be changed by this insertion. Do you wish the letter 'A' to be inserted into this document?]

One suggestion is to have a cache of trusted certificates for signed executables. But I strongly feel this should not be a default way of operating. It will add more burden to getting things done and make development and regular installation under all the different supported sub-platforms (BSD, X11, Java, Cocoa, Carbon) more difficult. Also, Apple would almost be guaranteeing a future 'security crisis' if one of the certificates got out or got cracked.

No. A simpler way, is to tell users not to take candy, or hot dogs, from strangers.

---
Carlos D
===
my music
http://music.altamar.dynalias.org/

Attempting to always protect people from their own stupidity, naïveté, or willful ignorance only manages to make lawyers everywhere richer.

OK, I'll put it out there. What recovery options work for each system. Sure, I could reinstall apps and data from backups, but a faster app or option? Diskwarrior, Norton, or reading raw disk data and rewritting? I must admit, I don't know how rm deletes files/directories.

i've looked all round since reading about this second cry from Intego, and until i checked ten minutes ago, my usual virus info sources (McAfee, Symantec, and Sophos) had nothing on it. Even now, Sophos does not list it.
i really think this is a non-issue. It's stupidity to get something like that from somewhere *other* than a reputable download site (i don't use P2P, so i have no idea how that works) like the company itself or VersionTracker. i'm also not worried about it because *it doesn't go crawling around by itself!*
i've just spent the last week up to my eyeballs in Windows workstations suffering from this last nasty Windows worm (and as an adjunct, clearing off all the spyware that has gotten on them). This is happening in a huge school district with firewalls, etc. Every four to six months we go through this. The only folks still working are the ones who are using Macs for the bulk of their work (except for what requires a Windows station).
i've read all the posts, here and other places, and i really don't think i need to alert the schools i'm responsible for about this; i also don't think i'll ever need to alert them about a Windows-style worm attacking Macs. i don't think it's because, as many 'experts' claim, the user-base is so small that there just isn't the interest in it. i think that Apple has been more diligent than Microsoft in creating tight code and not leaving loopholes.
Someone tried to counter me on that, saying that the 'loophole' was because of the wonderful Macro feature of Windows (sounds like he bought in to the rhetoric!), and it was because Windows was so wonderfully programmable that it was vulnerable. i just pointed out AppleScript.
In over a decade of owning Macs, the only antivirus i've ever run is Disinfectant, and i stopped that with OS9. Even pre-9, i never had nVIR or WDEF; with 9 and X, i've never had anything. No, not even the AutoStart worm, as i had the auto-play turned off anyway. i run no Microsoft products and no antivirus.
So i'm pulling my hair out and cursing the PCs at work, then, whilst those workstations chug away at the interminable Security Updates and virus scans, i pull out my iBook and start blithely checking email, surfiing, and listening to audiobooks.
Windows? Virii? *Phooey!*