Michael Ash wrote:
Malevolent process C fails.
Or maybe malevolent process C works because it's running with the same uid as unprivileged process A. The sticky-bit on a directory only prevents one uid from interfering with another uid's files. It has no effect if the uids of the processes are the same.
Having the same uid would not be unusual if the attack works by creating an unprivileged lurker that does nothing until an attempt is made to communicate with a privileged process using the vulnerable / tmp/ipc mechanism. An unprivileged launch-agent with an innocuous name might even arrange it so launchd is doing the "watch for change at /tmp/ipc" on its behalf. Refer to 'man 5 launchd.plist' and think of devious underhanded ways to use each feature.
This would be a local privilege escalation, and it might not be noticed for some time if the trojan that adds the launch-agent performs a useful function. Or even if the trojan didn't perform a useful function, but seduced users into just one trial-run. Even after the trojan is deleted, it can still leave its malicious (yet patient) payload behind.
If you think you couldn't possibly succumb to this tactic, when was the last time you used the 'launchctl list' command, and confirmed that every active job was one you wanted and knew about? And what about all the users who have no idea how to use Terminal.app or the 'launchctl' command?
Not every attack will be from the front, nor will every traitor instantly reveal its treachery.
-- GG _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
