[Nobody]

I, for one, want to thank you, Rob, for doing this article. No one ever takes the time to demystify this stuff. Just broad brushes about evil malware. I really, really, REALLY appreciate the work that you and Kirk did.
The Terminal explanation is wonderful; I'm gradually getting over my fear of it by reading your hints website. [I wish you would go back into this article and explain the difference between setting up Bonjour iChat vs Internet iChat--where do I find that?]
Whoever wrote that hideous remark to you can damn well stuff it.

[MacCheetah3]

Hi
Originally posted by righteousnite

In reply to:

---

[I wish you would go back into this article and explain the difference between setting up Bonjour iChat vs Internet iChat--where do I find that?]

---

From the iChat Help ( While in iChat go to the Help menu )...

In reply to:

---

Chatting on your local network
You can chat with other iChat users on your local network without using an instant message account or server. Each computer communicates directly with its neighbors.
Choose Window > Bonjour. Other iChat users who are on the same network segment, or subnet, as you appear in the window. To send a message, double-click a person in the list.
After the person accepts your invitation to chat, they can see your messages as you type them. Each character you type is sent immediately. If you want others to see your message only after you've finished typing all of it, change the "Send text as I type" setting in the Accounts pane of iChat Preferences.
The names shown in the Bonjour window are based on the login settings for other computers on the network. If you're sending an important file or message to someone, you might want to verify the person's identity.
If you don't want to use Bonjour messaging, you can turn it off in the Accounts pane of iChat AV Preferences.
If you connect to the Internet using PPP (or PPoE), you won't see other Bonjour users. If you connect via a shared network segment, which is common with cable modems, you may see other iChat AV users.
When firewall protection is turned on in the Network pane of System Preferences, you might be unable to receive messages from other Bonjour users. To use Bonjour, you need to allow activity on port 5298. See Mac Help for information on changing your firewall settings.

---

[Nobody]

Thanks, MacCheetah.

[Macaday]

I like the idea of the Mac community being intolerant of things which have become the norm in the Winbox world. Surely, with emails and the original posting of this app on MacRumors there is a possiblity of tracking the author of this? If he were appehended and brought to account it would strike another blow on behalf of all of us who detest this kind of attack our society.

[ckasper]

One could just do the inevitable. Subscribe to an AV service such as Symantec AV Corporate Edition, McAfee, or <insert your vendor here>. Then the end user doesnt have to be encumbered with all of the nonsense people are suggesting.
The vast majority of Mac users seem to want to keep things easy to use. What could be simpler?
It's not like the average mac user isnt willing to spend big bucks for their computer. Might as well spend $50/annum more to make sure it stays operable at least until open source and free software becomes available. It's just the cost of doing business. No brainer.

[robertRoss]

Agreed. We do the same for our Windows systems and have had any problems for years. Except if Symantec products are used. Commercial malware in my book.

[flowney]

Earlier descriptions of Leap-A said that an admin PW was required when one "executed" the script disguised as a JPEG. Did this not happen here?
As well, one would expect the OS to notice a discrepancy between the file suffix (*.jpg ?) and the launching of Terminal and execution of a script. Is this how MacOS X should adapt to this situation or do you have other ideas on how to help MacOS X users better recognize a 'dangerous' move is about to be taken.

[griffman]

"Earlier descriptions of Leap-A said that an admin PW was required when one "executed" the script disguised as a JPEG. Did this not happen here?"
No password is required.
"As well, one would expect the OS to notice a discrepancy between the file suffix (*.jpg ?) and the launching of Terminal and execution of a script. Is this how MacOS X should adapt to this situation or do you have other ideas on how to help MacOS X users better recognize a 'dangerous' move is about to be taken."
One thing that could be done is a first-time-run warning if you launch a Unix script from the GUI, much like what happens when you install a new widget. That would catch this thing before it had a chance to infect the machine.
-rob.

[lkalliance]

I was able to create the example of a non-admin-owned app trivially. Logged in as a non-admin user, I download any drag-and-drop application (the one I tested moments ago was the freeware Tetris game "Quinn", which I've never installed before). I drag it from the disk image directly into Applications, and I'm asked to Authenticate. I do, with my admin password, and it copies to the Applications folder. I go to Applications, check permissions on the app...and it shows it as owned by the non-admin user.
So that situation existed just with the simple, expected operation of adding an app.

[jmincey]

"One thing that could be done is a first-time-run warning if you launch a Unix script from the GUI, much like what happens when you install a new widget."
Hmm, lots of Aqua apps make calls to UNIX scripts. This could be a very intrusive behavior. And the definition of "first-time" or "one-time" might be problematic and not as simple or straightforward as one might think.
For example, suppose a particular web site makes a call -- one which is authorized and legitimate. Does OS X define "first time" by Safari, the URL, the web site, or the domain? How would this affect routines written in PHP, Javascript, Ruby, PERL, Python, et. al.? Would OS X consider those examples of UNIX shell scripts or are we talking only about scripts native to the shell itself, as in Bourne, C, Bash, etc?
Apple's own Network Utility makes extensive use of UNIX scripts. Do we define first-time on the basis of this GUI utility itself or on the basis of each different script it tries to run, whether it be whois or ping or netstat, etc?
I'm just posing questions and thinking out loud; it's an interesting idea in any event.

[griffman]

I was actually just trying to refer to things that are Unix scripts saved as GUI executables, which is what Leap.A is. That is, a program that has no GUI other than "open Terminal and run this." The first time you ran such a thing, you'd be asked "are you sure?" and perhaps it lists the script, or tells you (as in this case) if it's compiled.
I agree that catching any Unix call in any app will be problematic, at best. At some level, we have to let code do what it wants to do. But something like this would catch the simplistic stuff at least. Much like widgets -- we now accept a widget as being safe to run, but the author could still hide any code inside the widget that they'd like to.
-rob.

[lkalliance]

But it's this kind of thing for which we're willing to have spent the money in the first place. The lack of an annual antivirus fee is part of what we're paying for.
Be that as it may, these are exactly the kinds of things we (more experienced Mac users) should be trying out. Because if it IS something as simple as running as a non-admin that create inherently better security, and if there IS an intuitive way to set it up, then the rest of the Mac community benefits. I might have the experience and patience to work with permissions and such, but my mother doesn't, for example. But when we do find a simple, non-intrusive and maintenance-free way to protect our computers, then my mother will benefit.

[galendw]

" "Earlier descriptions of Leap-A said that an admin PW was required when one "executed" the script disguised as a JPEG. Did this not happen here?"
No password is required."
Well, did you run it from an admin account or from a standard account? I heard that it only required a password if it was run from a standard account. (If that's true, it's a good reason to use a standard account for everything except admin activities.)

[griffman]

"Well, did you run it from an admin account or from a standard account? I heard that it only required a password if it was run from a standard account. (If that's true, it's a good reason to use a standard account for everything except admin activities.) "
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. Even though an admin can modify a system-owned package by authenticating, no dialog appeared. Console merely reported that the Input Manager could not be opened.
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.
-rob.