Gregory's Server|
3 comments
 The translator notices this and creates a new auth handle based on its idea of your effective uids/gids (see libfshelp/exec-reauth.c); and then the exec server gives the new task a fresh proc port. You cannot access the new task because of setuid/EXEC_SECURE, but as you created the executable you still control what it does. In particular it may send its proc/auth ports back to the original task, and the original proc port may then be recovered by a simple proc_task2proc (other_proc, mach_task_self (), &my_proc) The exact auth port I don't think can be recovered, but at least you now have another auth port with your effective uids/gids. |
@civodul
Yes, /servers/proc is not it :)
I was thinking of the following scheme, which I have not tried, so this is just a theory.
You create an executable (perhaps as an unnamed file) that is setuid to yourself, and then exec it (not over your own task, unless you want that), without passing an auth or proc ports (as you have none).
@janneke