Saturday, June 24, 2006

mach_inject, procmod group and security

mach_inject is a very clever piece of hack that allows an application to inject and execute code in another running process. It was initially written for PowerPC Macs only. Recently, Bertrand Guihéneuf ported mach_inject for Intel Macs.
The big difference between the two version lies in the privilege level they require. The PowerPC version works with standard user privilege whereas the intel version requires more privileges to work.

mach_inject is used for example by virtual desktops applications like Desktop Manager and VirtueDesktops. They legitimately requires the ability to inject code in the Dock as it is the only process allowed to manipulate all the windows. But running code under the identity of another process is a high security risk. That's why Apple introduced a new security feature in Mac OS X 10.4.4 (for Intel Macs only) that prevents mach_inject to work. Technically, any process not belonging to the procmod group or not running as root will fail to call task_for_pid which is a necessary step in the process of code injection.

There are several solution to this problem which are not all equivalent from a security point of view.
The first solutions that surfaced were proposed by Jason Thames on osx86project forum.


  • His first proposal is to add yourself to the procmod group.
  • His second proposal is to change the security policy of the task_for_pid call.
Unfortunately, both solutions are bad solutions, the former at a single user level, the latter at the computer level.
Doing so would now allow any application to inject code into another process meaning that you would have annihilated the protection introduced by Apple. :-(

The good solution is to set the permission on a per application basis rather than on a per user/computer basis. Unix permission mechanism is perfectly suited to perform this task. You can do it manually with a terminal, Niko explains the procedure on his blog. This works very well but is a bit tedious for users reluctant to use a terminal.

The best solution is that developers who legitimately require mach_inject functionality make use of the Security/Authorization API for asking users their administrator password in order to be able to change their application's executable group to procmod and set it's set-group-ID-on-execution bit. VirtueDesktops is the first to my knowledge to do so. You can see the source on VirtueDesktops trac to understand how this can be performed.

I strongly encourage developers to use the self-authorizing mechanism mentioned above as this will be beneficial for users both in a security and an ergonomic point of view.

keywords: mach_inject, procmod, task_for_pid, security, intel

3 comments:

Jaka Jancar said...

Hi!

Just stumbled on this, now quite old, post, and I'm wondering, doesn't setting SGID then allow _ANY_ user to run the app as that group?

That means if they find a hole in the application, say VirtueDesktop, that I have installed, they can alter any process?

If that's the case, it might make sense to also restrict access to the application in question to just the users you trust, instead of leaving it world-readable/runnable.

Jaka

Anonymous said...

Can anyone confirm if this technique still works in Snow Leopard. Whatever I try, the underlying mach_inject call always return an err of 5 and tells me to add to procmod.

Thanks

agile said...

take a look on good solution:
http://os-tres.net/blog/2010/02/17/mac-os-x-and-task-for-pid-mach-call/