The First Mac OS X Virus?

[BobVB]

You should've switched to your "clawed" account before installing the new version.

Well like so many apps there is no 'installation' its just a file that auto unpacks and there's the application in a folder with assorted readme's and other useless stuff.

Again, should be fixed by Apple - it is unreasonable to make someone switch to another account just to unpack files. Needs to somehow id the apps and make them owned and grouped to an admin account. It should ask for the admin account and password before unpacking apps perhaps. But however its done the non-admin user has to be able to download application containing files without switching accounts and still end up with a system secure end-product for dropping in the Applications folder.

Seems to me.

 

[dejo]

Well like so many apps there is no 'installation' its just a file that auto unpacks and there's the application in a folder with assorted readme's and other useless stuff.

Again, should be fixed by Apple - it is unreasonable to make someone switch to another account just to unpack files. Needs to somehow id the apps and make them owned and grouped to an admin account. It should ask for the admin account and password before unpacking apps perhaps. But however its done the non-admin user has to be able to download application containing files without switching accounts and still end up with a system secure end-product for dropping in the Applications folder.

Seems to me.

Okay, but it seems reasonable, to me at least, to have to switch to an admin user in order to drop the new version of an product into the Applications folder.

 

[p0intblank]

In relation to Arch's post... is this sort of exploit able to be patched? Do you see Apple releasing a patch in Software Update within a week or so?

 

[JoE950]

I dont know if this has been posted, but NEVER double click on files.

either open via right click and select the appropriate application or drag them to the app icon of choice in the dock.

this will alert you to any problems, because if its a unix executable it wont begin its dirty work in regular apps (if it will even open) and if you right click, its going to give you options like "open in terminal" and that should set up a FREAKING HUGE RED FLAG that what you are about to do is most likely unfavorable.

i have practiced this method for a couple years now just to make sure jpgs didnt accidentally open in photoshop (the emac was slow...) when all i wanted was a quick preview.

 

[BobVB]

Okay, but it seems reasonable, to me at least, to have to switch to an admin user in order to drop the new version of an product into the Applications folder.

Yeah was thinking about that - maybe let it make the standard user permissions when it initially unpacks it so its a local product but then when dragged to the Applications folder it asks for the admin account and THEN changes it to the admin permissions along with the move.

That way if you've downloaded a program it doesn't have admin permissions until you've committed to saying 'this should be available globally'.

 

[mdavey]

You should've switched to your "clawed" account before installing the new version.

<unix technical discussion>

The ability to install an application with the standard users' ownership is not ideal. Even /Applications directory owned by root and with sticky bits set isn't a solution as Mac OS X ignores the sticky bits when moving or copying files (although in this scenario it does at least ask for an admin username/password before installing the application with the standard users' ownership).

</unix technical discussion>

 

[dejo]

Yeah was thinking about that - maybe let it make the standard user permissions when it initially unpacks it so its a local product but then when dragged to the Applications folder it asks for the admin account and THEN changes it to the admin permissions along with the move.

That way if you've downloaded a program it doesn't have admin permissions until you've committed to saying 'this should be available globally'.

My standard practice is to download, unpack and 'install' any new apps and any upgrades from within my admin user.

 

[Doctor Q]

I think I speak for a whole lot of people when I say...

HUH?!?!

Declaw? Demote? Use an admin at this time, but not at that time? /$ r/-s???? Somebody please clear all this up for me before I decide that the Macintosh world as I knew it is dead forever.

Using Terminal is NOT the proper way to go about fixing the potential security problem of this Trojan horse. It's just a way that some people (not everyone) can make themselves a little more secure promptly while we wait for a better solution.

The proper solutions are education (ways to keep people from being prone to Trojan horses) and possible changes to Mac OS X, such as keeping Applications from being writable during normal use of the system (with various ways suggested for how to accomplish this.) Whether there should be more and different warnings issued when you download or launch applications is worthy of discussion.

Because most Mac users would not want to use Terminal, most should not have to use Terminal, and the vast majority will not read forums like this, the problem can only be solved (or "addressed", since an absolute and foolproof cure for every possible invasion is out of the questions) is for changes to the default way we operate. And changing software is a lot easier than changing people's behavior.

So don't panic over this particular malware. You know not to download it. You know not to double-click if you download it. You know not to type your admin password if you double-click it. So you are already safe from this one. You can keep using your Mac as you have always been.

 

[shrimpdesign]

so, everyone who bought an x86 Mactel, welcome to thunderdome b****.

Soooo... you're uninformed. Did you even read any of this thead? Leap-A doesn't even run at all on Intel Macs because it wasn't comiled with gcc 4.

 

[BobVB]

My standard practice is to download, unpack and 'install' any new apps and any upgrades from within my admin user.

Yeah but lets face it, any account switching will be unacceptable from an user friendly end-user standpoint and its just not going to happen. Apple needs to figure a way to just be able to 'call up' the admin abilities when needed from any user account. It already does for most things - now they need to figure out a way to do it for things added to the Applications folder. Maybe something as simple as special 'add to Applications' droplet or Finder menu command that confirms the admin account and then changes the file's permissions to that account before moving it. That would also allow them to avoid the 'don't have permission to replace this file' on a version upgrade.

 

[dejo]

Yeah but lets face it, any account switching will be unacceptable from an user friendly end-user standpoint and its just not going to happen. Apple needs to figure a way to just be able to 'call up' the admin abilities when needed from any user account. It already does for most things - now they need to figure out a way to do it for things added to the Applications folder. Maybe something as simple as special 'add to Applications' droplet or Finder menu command that confirms the admin account and then changes the file's permissions to that account before moving it. That would also allow them to avoid the 'don't have permission to replace this file' on a version upgrade.

Sure, but sacrificing security in exchange for user-friendliness is a HUGE reason that Windows is the mess it is today.

 

[BobVB]

Sure, but sacrificing security in exchange for user-friendliness is a HUGE reason that Windows is the mess it is today.

But how is it more secure? We have the typical setup of a single person using the mac - they ARE the administrator even if they are using a regular account. How does it make it more secure making them switch accounts to put something in the Applications folder over just confirming they are the administrator and doing the exact same thing from their regular account?

 

[mdavey]

Yeah but lets face it, any account switching will be unacceptable from an user friendly end-user standpoint and its just not going to happen. Apple needs to figure a way to just be able to 'call up' the admin abilities [for things added to the Applications folder] when needed from any user account.

<more technical stuff>

Appl need to make OSX obey the Unix permissions.

If /Applications is owned by root:admin and has permissions 6775 then Mac OS X already gives a permission denied dialogue and an option to authenticate as an admin user.

All that is needed is for Mac OS X to then obey the Unix sticky bits and change ownership of the new application to be the same owner and group as the enclosing (that is, /Applications) directory itself.

</end>

 

[winmacguy]

Looks like a few online news sites are starting to run the story although some of the reports are somewhat misleading

First virus hits Mac OS X
http://australianit.news.com.au/articles/0,7204,18176910^15306^^nbv^,00.html

New malware targets OS X chat users
http://news.com.com/New+malware+targets+OS+X+chat+users/2100-7349_3-6040681.html

World's first OS X virus hits Apple The iChat malware has been dubbed Leap-A by antivirus firm Sophos
http://www.computerworld.com/securitytopics/security/story/0,10801,108784,00.html?source=x10

 

[jer2eydevil88]

Security by obscurity no more.......

Now the real question is how long will it take for Apple to fix this? Will we see them be the Mozilla of the world and have a patch in 24 hours? Or the Microsoft of the world and see a patch 2.5 years from today with the release of OS X 10.6

.:: Edit ::.

Something tells me this is the fallout from the work over at http://www.projectosx86.org as there are now thousands if not tens of thousands of hackers/script kiddies who formerly only used Macs at the library can now play with the OS at home.

 

[Diatribe]

...

You know not to type your admin password if you double-click it. So you are already safe from this one. You can keep using your Mac as you have always been.

Thing is though that it doesn't ask for your admin pw if you are logged in as admin.

 

[chargoy]

Dark Days

I sense a plot to destroy the Apple

 

[StarbucksSam]

I'll be starting an iChat room for discussion of this if anyone wants to join me. I can't vouch for who will be in it or when, but if you're interested, it's room macvirus on iChat/AIM. IM me if you want.

Wow. I feel like the Berlin Wall just fell again.

 

[dejo]

But how is it more secure? We have the typical setup of a single person using the mac - they ARE the administrator even if they are using a regular account. How does it make it more secure making them switch accounts to put something in the Applications folder over just confirming they are the administrator and doing the exact same thing from their regular account?

Both methods are equally secure, true. The fact that you want it to ask for a password shows that you are not willing to sacrifice security for user-friendliness. The point I was making was that Windows became such a security-risk partly because Microsoft decided they didn't want to inconvenience the users (lessen the user-friendliness). I'll admit though that balancing security needs with user convenience can be a tricky act.

 

[yankeefan24]

found a file in package contents inside of iChat. Opening this file opened iChat and sent it too one person on your buddy list at a time through AIM. NOTE: I preformed this on an account that has no buddies accept AIM bots (which AIM puts there)
copied from terminal:

/Applications/iChat.app/Contents/MacOS/iChat; exit
2006-02-16 19:24:32.255 iChat[2303] CFLog (0): CFMessagePort: bootstrap_register(): failed 1103 (0x44f), port = 0x3e03, name = 'com.apple.iChat.ServiceProvider'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2006-02-16 19:24:32.315 iChat[2303] CFLog (99): CFMessagePortCreateLocal(): failed to name Mach port (com.apple.iChat.ServiceProvider)
2006-02-16 19:24:35.973 iChat[2303] WARNING: Service[AIM] chat:messageReceived: chat '-shoppingbuddy' is not known
2006-02-16 19:24:36.013 iChat[2303] WARNING: Service[AIM] chat:messageReceived: chat '-moviefone' is not known

EDIT: more for iChat, there are alot of features apparently hidden in iChat that you can see by looking in the resource folder. like tab close icon (a sign of the future) and some random smilies not in ichat. interesting what this can do.

 

[BobVB]

Appl need to make OSX obey the Unix permissions.

If /Applications is owned by root:admin and has permissions 6775 then Mac OS X already gives a permission denied dialogue and an option to authenticate as an admin user.

All that is needed is for Mac OS X to then obey the Unix sticky bits and change ownership of the new application to be the same owner and group as the enclosing (that is, /Applications) directory itself.

Yes in fact didn't early OS X do just that whenever you tried add an application to the Applications folder? Now, even though it is owned by the system, it lets me add and remove things at will even from a non-admin account.

 

[winmacguy]

Security by obscurity no more.......

Now the real question is how long will it take for Apple to fix this? Will we see them be the Mozilla of the world and have a patch in 24 hours? Or the Microsoft of the world and see a patch 2.5 years from today with the release of OS X 10.6

.:: Edit ::.

Something tells me this is the fallout from the work over at http://www.projectosx86.org as there are now thousands if not tens of thousands of hackers/script kiddies who formerly only used Macs at the library can now play with the OS at home.

I'm not sure how Apple would "patch" this one... considering PC viruses utilise the autorun feature which is not part of OS X. This particular bit of malware requires user intervention ie you have to install it/activate it yourself for seomthing to happen - a bit like an application.
http://en.wikipedia.org/wiki/Computer_virus

 

[nagromme]

Lots of great, intelligent discussion. Thanks, all!

Is there some irony to the fact that this thread has fewer flames and less ignorance and less Mac-bashing than any new-product thread?

BTW, re the idea that apps should not be writable. How would that affects apps that are customized using their package contents? (Like UT 2004--adding maps is done inside the package--or can be, at least.) Do you mean the literal executable itself would not be writable? Or the entire surrounding package?

 

[winmacguy]

Lots of great, intelligent discussion. Thanks, all!

Is there some irony to the fact that this thread has fewer flames and less ignorance and less Mac-bashing than any new-product thread?

BTW, re the idea that apps should not be writable. How would that affects apps that are customized using their package contents? (Like UT 2004--adding maps is done inside the package--or can be, at least.) Do you mean the literal executable itself would not be writable? Or the entire surrounding package?

I guess it is a bit hard to bash/flame ourselves when we are having a discussion to find out the whys and wherefores on how the trojan works and how not to have it installed on OS X. Its a bit like discovering a pre-press issue at work on a system that should be immune from the situation and having a discussion with 300 informed people as to how to solve or avoid the issue next time it surfaces.

 

[mrichmon]

BTW, re the idea that apps should not be writable. How would that affects apps that are customized using their package contents? (Like UT 2004--adding maps is done inside the package--or can be, at least.) Do you mean the literal executable itself would not be writable? Or the entire surrounding package?

Many apps (including Adobe products) write data into the application contents when it is first run. Commonly this is used to save serial numbers and the name of the owner and business. If the application contents is not writable then this becomes a problem.

If only the literal executable is not writable but the application folder structure is writable then you have not solved the original problem. For example, take TextEdit.app. Within TextEdit.app is a Contents folder. Inside the contents folder is a MacOS folder. Inside the MacOS folder is the executable TextEdit.

Now, assume that TextEdit is not writable by anyone, but the MacOS folder is writable as you suggested. Since the folder is writable, it is possible to create a new folder in MacOS called trojanHackmaster. Since the MacOS folder is writable it is also possible to move the TextEdit executable into the trojanHackmaster folder even though the TextEdit executable is not writable by anyone. Moving the file between folders is determined by the folder permissions, not the permissions of the file being moved.

Now that the TextEdit executable has been moved, a new executable named TextEdit can be saved into the MacOS folder. This executable can do whatever it likes to the system (within the current user or application permissions). If the new executable then executes the trojanHackmaster/TextEdit executable when it has finished its nasty work then the end user will not be aware of any difference in the application.