Linked by Kroc Camen on Thu 22nd Jan 2009 17:52 UTC
Privacy, Security, Encryption "Intego has discovered a new Trojan horse, OSX.Trojan.iServices.A, which is currently circulating in copies of Apple's iWork 09 found on BitTorrent trackers and other sites containing links to pirated software. The version of iWork 09, Apple's productivity suite, are complete and functional, but the installer contains an additional package called iWorkServices.pkg." Update: A new variant has been discovered in a pirated version of Adobe Photoshop CS4, also information about one target of a DDOS attack coming from the trojan.
Thread beginning with comment 345092
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: I blame Apple
by pcunite on Thu 22nd Jan 2009 23:10 UTC in reply to "I blame Apple"
pcunite
Member since:
2008-08-26

Unfortunately, when I update my Ubuntu box, it seems to always want root, and I grudgingly give it. But, as a rule, it's simply a bad habit, and should be discouraged. It would be interesting to know if Apple could have worked around the need for iWork to have root access during install through some other mechanism.


You thinking is close but needs just a little bit of clarification. The reason installs require root is because AFTER the install is complete it is the only way to harden a system. Most people don't run hardened systems but for those of us who do consider:

1. An executable can write to a directory. That same directory can not be executed from.

2. A directory that can be written to must not ever allow executions from.

To achieve those two points the software must be run under a limited account. The exe can run from C:\Progs but only write to C:\user\desktop. C:\Progs can never be written to by the user. The user can write a file to their desktop using notepad.exe. An exploit to the web browser would not allow a virus to live on the system.

Thus an installer must be ran as root because not only must it execute, it must write to a directory that will later be executed from.

I did not explain this the best way but hopefully you got it!

Reply Parent Score: 3

RE[2]: I blame Apple
by whartung on Thu 22nd Jan 2009 23:42 in reply to "RE: I blame Apple"
whartung Member since:
2005-07-06


1. An executable can write to a directory. That same directory can not be executed from.

2. A directory that can be written to must not ever allow executions from.

To achieve those two points the software must be run under a limited account. The exe can run from C:\Progs but only write to C:\user\desktop. C:\Progs can never be written to by the user. The user can write a file to their desktop using notepad.exe. An exploit to the web browser would not allow a virus to live on the system.

Thus an installer must be ran as root because not only must it execute, it must write to a directory that will later be executed from.


That's all well and good. And as long as that process is provided by the "system", i.e. a "trusted agent", rather than "joe random installer that I just authorized", then that could mitigate the problem nicely. The system process can ensure that the privileges of the newly installed exe won't get inadvertently promoted to super user.

In this trojans specific case, the major problem was that this exe got installed with SU privileges. If it was installed with my "generic user" privileges, it's no less a potential breach (it could be "loaded automatically", send sensitive documents to an outside party, etc.), but its capability to continue to do harm is limited by my weaker privilege set. (i.e. it can't download a new kernel module that roots my system even more).

Reply Parent Score: 2

RE[3]: I blame Apple
by pcunite on Fri 23rd Jan 2009 03:57 in reply to "RE[2]: I blame Apple"
pcunite Member since:
2008-08-26

[qThat's all well and good. And as long as that process is provided by the "system", i.e. a "trusted agent", rather than "joe random installer that I just authorized", then that could mitigate the problem nicely. [/q]

You are correct. We have to know we can trust the software. That is why I am very careful of what I install. At some point there is initial risk.

Reply Parent Score: 1

RE[3]: I blame Apple
by lemur2 on Fri 23rd Jan 2009 04:03 in reply to "RE[2]: I blame Apple"
lemur2 Member since:
2007-02-17

That's all well and good. And as long as that process is provided by the "system", i.e. a "trusted agent", rather than "joe random installer that I just authorized", then that could mitigate the problem nicely. The system process can ensure that the privileges of the newly installed exe won't get inadvertently promoted to super user.

In this trojans specific case, the major problem was that this exe got installed with SU privileges. If it was installed with my "generic user" privileges, it's no less a potential breach (it could be "loaded automatically", send sensitive documents to an outside party, etc.), but its capability to continue to do harm is limited by my weaker privilege set. (i.e. it can't download a new kernel module that roots my system even more).


I think you may have the wrong end of the stick here.

On Windows and, to a lesser extent, Mac OSX, the end users are accustomed to installing stuff for which they have no possible way to vet it. One gets a binary (somehow), and apart from the blurbs (which are written after all by the author of the software) one has no objective way to assess what is in the software and what it will do.

Asking for the root password on installation does nothing really with such a paradigm. End users will just be accustomed to giving it when they want to install anything. All that giving the root password does is identify that the person doing the installation is probably authorised to do so for that machine.

The only real way to ensure that the software one is about to install is not malware is to have everyone who uses the software able to inspect the source code at will. There will be enough people in the userbase who can audit the code functionality, and compile the software for themselves to verify that the distributed binary matches the source, that all people in the userbase can be assured that it is not malware.

Anything else ... involving customarily installing closed-source binary-only software ... will lead to the possibility of being compromised via trojan horses.

Edited 2009-01-23 04:05 UTC

Reply Parent Score: 2

RE[2]: I blame Apple
by Havin_it on Fri 23rd Jan 2009 18:57 in reply to "RE: I blame Apple"
Havin_it Member since:
2006-03-10

I think you nailed it*. I have tried to follow this philosophy on my various Windows installs, by revoking execution perms from a Limited User's writeable folderspace. It does cause problems with many benign but lazily-designed apps, though. A large part of this is probably because Windows (NTFS) permissions instantiate this permission not on its own, but as the "execute files / traverse directory" permission, which means the revoked user can't, for example, DIR or CHDIR in these folders. I've never heard a reasonable explanation of why these two disparate permissions are fused together in Windows; if anyone has, I'd love to hear it.

*Of course, we have to trust the installer itself not to do anything naughty. It would be nice if Windows was tooled to enforce their behaviour to stick to the above, but I can't see that ever happening when they can't even set sensible default permission-layout ;)

Reply Parent Score: 2