[AlanOpp]

Excellent article, thanks. We're going to refer to it in our Mac Internet security blog at http://www.isfym.com. One comment on a recent post:
"We tested from admin accounts, as the vast majority of OS X users use their machines in that manner. If you ran as a non-admin, based on what we saw, you probably would not see a password prompt; the script would simply die. That's what happened when we tried to get it to infect system-owned apps when we were logged in as admins."
The password prompt is, I believe, for installing the InputManager hook in the first place (not something non-admin users should be doing), not for having it run from a system-owned app.

[griffman]

Since the input manager is installed in the user's Library/InputManagers folder, there shouldn't be a password dialog. Everything in the user's Library is (with a few exceptions) user-owned, and even non-admins have write privs in their Library.
-rob.

[galendw]

"So would it be safer to run as a non-admin? Yes, with one large caveat: it would be safest if that account is a non-admin account used from the get-go, with all applications installed by a separate admin user. If you merely convert an existing admin account to non-admin, it will still own a large number of the applications, which would (in theory) mean they're now infectable, even though the Applications folder itself is safe."
Easy. First switch to an admin account, then run this terminal command:

code:
sudo chown -R root:admin /Applications/

---

<<Warning: This will change the owners of all files, folders, and apps in your Applications folder and every folder inside it.>>
You'll have to enter your password and repeat the command for anywhere else you may keep applications. Of course this is only really effective if you're not an admin. The only downside (there's always a downside) is that you'll have to repeat it for every new app you install after you first run it, which can be a hassle.

[jmincey]

That may not be enough; you may have to run chgrp as well.
Ordinary users should not have to concern themselves with chown, chgrp, chmod, etc, to say nothing of using them recursively. One false move and the mother of unintended consequences comes down hard o.n you -- especially with that -R argument.
(To prevent Macworld's "moral filter" I had to insert a period in the word, on, above; Macworld's stupid internal censor is over aggressive and doesn't understand that the phrase containing "hard" and "on" is actually hyphenated or that there are legitimate uses for this phrase.)

[TerryM]

Regarding the "trojan" aspect of this thing, it seems little attention has been paid to the fact that it arrives as a unix archive, a .tgz file, which in my book is a very unusual occurrence. Maybe that's not such a big thing, but I honestly can't remember the last time I downloaded such an archive, if I ever have at all.
And since this thing was masquerading as a jpeg (jpegs?), why didn't the trojan author distribute it as a regular zip or rar archive, which is the common (if not universal) method for distributing pic collections? (But not just a single solitary jpeg file, and one without the customary .jpg extension at that - another red flag).
I noticed in the blow by blow description of how it works, the first thing that appears to happen is the terminal is launched in the background. Could that have happened if this was delivered as a regular zip file or is the action of automatically launching the terminal by the trojan something that required it to be delivered as a .tgz archive? Or maybe the author was just having a whopper of a unix moment when he packaged the trojan as a .tgz?

[griffman]

Actually, it really didn't matter what compression he used -- the first thing you do is expand the archive, then you double-click the resulting fake JPEG. It's the fake JPEG that opens Terminal, not the archive.
-rob.

[Peter Cohen]

In reply to:

---

(To prevent Macworld's "moral filter" I had to insert a period in the word, on, above; Macworld's stupid internal censor is over aggressive and doesn't understand that the phrase containing "hard" and "on" is actually hyphenated or that there are legitimate uses for this phrase.)

---

Oh, Jeff. Stop acting like such a hard o.n.

[AlanOpp]

I think maybe the virus first tries to write to the system Library folder. Something seems to cause a password to come up if you're not running with admin privileges, at least according to most reports. It might be worth trying in your "lab" anyway.

[Nobody]

Here's what I've done so far to protect myself from this sort of thing:
-made a new admin account
-demoted my regular account.
-Switched to new admin
-run terminal
-go to Applications folder cd /Applications
-run 'sudo chown -R <adminname>:admin *.app'
-then run disk utility which switches all the Apple apps back to being owned by 'system'.
-Switch back to regular account.
I've also made sure show all file extensions are turned on. I know it's ugly, but oh well.
1. Is there anything else I need to be doing for more security?
2. Whenever installing something, what should be the proper procedure?
3. Do I need to be in admin to install using drag and drop?
4. Will I have to run that terminal code again after installing any new program?
I really appreciate any help you can give. I don't know a lot about stuff like this, so I'm trying to learn. Thanks for your patience. Sorry if I asked any stupid questions.

[fingal]

Let me comment on some of the questions about using a non-admin user for day-to-day tasks since I have actually been dong this for several years. I use three accounts. One is admin which I hardly ever use, a second, the account I use most often, is non-admin. Then I have an additional non-admin account which I only use for financial matters.
Innitially, with OS X, this was somewhat difficult to manage (though not as bad as Windows) but some additional features were added more recently to makes this easier. Fast User Switching is one but there is another important feature (which arrived with Panther, I think). This is the one where the Finder will allow you to enter an admin password if you want to copy files to a folder where you don't have permissions. This means that you can do drag-and-drop installs of applications from a non-admin account.
You drag the application to the Applications folder and then the Finder will give you a dialog box saying that you don't have write permission to that folder but there is an "authenticate" button on that dialog box. Hit that button, enter an admin password, and the copy process will proceed. The installed application will be owned by you (the non-admin user). I took a look at my system and a lot of applications are owned by the main non-admin user but none are owned by the financial non-admin user. So it looks like the situation which lkalliance discribed is actually normal for someone who follows the secure practice of logging in as a non-admin user.
There are also some other things which you can use to make working as a non-admin user easier, even for an advanced user like myself. For example, you can't sudo or su to root in the Terminal but you can take Terminal.app and drag it onto Pseudo to run a shell as root.
Here's another question. Are there any situations wherer changing the ownership of an application to another user will be a problem? Also, what if you tighten permissions for an application and, for example, deny write access to all regular users?