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

Attention: nouvelle campagne de phising contre PostFinance

On ne le répétera jamais assez, votre banque ne vous enverra jamais d'e-mail vous demandant de vous authentifier dans le jour même sous peine d'avoir votre compte fermé!

Voici l'e-mail que je reçu aujourd'hui comme beaucoup d'autres:


Lorsque l'on passe le curseur sur l'URL, on constate vite la supercherie: l'URL n'est pas du tout la même que celle annoncée dans le corps de l'e-mail. Une petite vérification avec un whois nous confirme que ce n'est effectivement pas le site web de PostFinance.

La nouvelle sur PostFinance

mots clés: phishing, PostFinance

Using GNU lightning on an Intel Mac

GNU lightning is a library that generates assembly language code at run-time. This is an useful tool for writing a Just-In-Time compiler.

While your jit compiled code will work on most systems, you will probably experience crash under Mac OS X with an EXC_BAD_INSTRUCTION exception on a movdqa %xmm0,32(%esp) instruction. The reason if this crash may seem obscure but is in fact simple: on Mac OS X, the stack must be 16-byte aligned at the point of function calls. This is documented in the Mac OS X ABI Function Call Guide.

So, how to fix this problem ? Align the stack manually by jit compiling special instructions before every function call depending on the number of parameters pushed ? This is quite tedious. A better solution is to use gcc's -mstackrealign switch.

Here is the documentation of this option:

-mstackrealign
Realign the stack at entry. On the Intel x86, the -mstackrealign option will generate an alternate prologue/epilogue that realigns
the runtime stack. This supports mixing legacy codes that keep a 4-byte aligned stack with modern codes that keep a 16-byte stack for SSE compatibility. The alternate prologue and epilogue are slower and bigger than the regular ones, and they require one dedicated register for the entire function. This also lowers the number of registers available if used in conjunction with the "regparm" attribute. Nested functions encountered while -mstackrealign is on will generate warnings, and they will not realign the stack when called.

Enjoy, your program is not crashing anymore. :-)

keywords: GNU lightning, Intel Mac, crash, EXC_BAD_INSTRUCTION, movdqa xmm0

Relaunch your Cocoa application by itself

Here is a code snippet of a relaunch helper tool with instructions to use it.

keywords: self, restart, relaunch, cocoa, os x