Gregory's Server
@bugaevc Possibly (but not necessarily) by looking up /servers/proc for the first one; as for auth, it’s forever lost?
|
4 comments
 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). 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. |
@janneke @bugaevc Actually I keep making the same mistake: there’s no /servers/proc but for some reason we have it in childhurds, just with no translator on it (I may be the guilty party :-)).