race for /proc/$PID/environ [was: procfs and privacy and a few other questions]

[Björn Steinbrink <B.Steinbrink@gmx.de>]

Hi,

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
for everyone.
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.

HTH
Björn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/