race for /proc/$PID/environ [was: procfs and privacy and a few other questions]
From: Björn Steinbrink
Date: Tue Jul 18 2006 - 18:59:57 EST
On 2006.07.19 00:20:20 +0200, Wolfgang Draxinger wrote:
> Another question, also on procfs is, where exactly does the race
> condition of the recently reported privilege escalation exploit does
> take place. In the few days I was experimenting a bit with the code,
> trying to inject non a.out formats, and eventually the Mono framework
> or the WINE wrapper could allow to inject code through a BINFMT_MISC
> handler, but I'm not through on this. Gladly the thing is fixed, but
> given the fact that there seem to be still a lot of servers on which
> even the sys_prctl exploit isn't fixed yet I'm a bit precarious about
> the whole situation.
The race happens between pid_revalidate() and proc_pid_environ(). When
sys_execve() is called, you get into prepare_binprm() which first checks
the i_mode flags and the owner of the file to be executed and later
tries to read the file.
When a process is set non-dumpable, its files are owned by root:root
while permissions are kept, and the "environ" file also gets non-readable
The owner is basically set by proc_revalidate(), the check whether
"environ" may be read happens in proc_pid_environ() (the call to
ptrace_may_attach() to be exact).
Now prepare_binprm() first gets owner and permissions, which are
root:root and 04755 respectively, permissions were changed regularly,
owner was set to root:root, because the process is non-dumpable.
Later prepare_binprm() actually tries to read /proc/$PID/environ and
usually this would fail, because the process is non-dumpable. Now, if
the syscall gets preempted in between these two, you can change the
process back to be dumpable, the read succeeds and that's it.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/