|Summary:||issue with core dump owner|
|Product:||Process Management||Reporter:||blake frantz (trew)|
|Component:||Other||Assignee:||Ingo Molnar (mingo)|
|Severity:||high||CC:||alan, matt, protasnb|
|Kernel Version:||2.6.x and 2.4.x||Tree:||Mainline|
Description blake frantz 2004-07-10 19:15:53 UTC
in 2.6.x and 2.4.x kernels, if a core file owned by a non root user exists and root runs a process that drops core in the same location, the original core file owned by the non root user is replaced with root's core dump, except the original owner maintains ownership of the core. obsd and fbsd operate in the same manner. i have not tested other platforms trew@uber:~/tmp/q$ ./t Segmentation fault (core dumped) trew@uber:~/tmp/q$ md5sum core 90b29a1012aa00c34a18947d98f1b1fb core trew@uber:~/tmp/q$ ls -l core -rw------- 1 trew users 61440 Jul 10 19:13 core trew@uber:~/tmp/q$ su Password: uber:/home/trew/tmp/q# ./t Segmentation fault (core dumped) uber:/home/trew/tmp/q# md5sum core 371c0748df009ed1da6f189cceff8aca core uber:/home/trew/tmp/q# ls -l core -rw------- 1 trew users 61440 Jul 10 19:13 core
Comment 1 Natalie Protasevich 2007-09-06 21:07:23 UTC
Is this still a problem with recent kernel? thanks.
Comment 2 Ingo Molnar 2007-11-17 18:18:21 UTC
Yep, still seems to be happening with 2.6.23.
Comment 3 Alan 2007-11-18 06:16:49 UTC
Cute.. that needs fixing
Comment 4 Ingo Molnar 2007-11-29 08:12:45 UTC
fixed upstream: commit c46f739dd39db3b07ab5deb4e3ec81e1c04a91af Author: Ingo Molnar <email@example.com> Date: Wed Nov 28 13:59:18 2007 +0100 vfs: coredumping fix fix: http://bugzilla.kernel.org/show_bug.cgi?id=3043 only allow coredumping to the same uid that the coredumping task runs under.
Comment 5 Matt McCutchen 2010-08-16 07:46:42 UTC
I don't think this fix is sufficient. If I happen to share a writable directory with the victim somewhere else, I can borrow a regular file owned by the victim from there and use it to perform the same attack. The safest approach would be to use O_EXCL all the time.