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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20060718230152.GA13303@atjola.homenet>
Date:	Wed, 19 Jul 2006 01:01:52 +0200
From:	Björn Steinbrink <B.Steinbrink@....de>
To:	Wolfgang Draxinger <Wolfgang.Draxinger@...pus.lmu.de>
Cc:	linux-kernel@...r.kernel.org
Subject: race for /proc/$PID/environ [was: procfs and privacy and a few other questions]

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/