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
Is this still a problem with recent kernel? thanks.
Yep, still seems to be happening with 2.6.23.
Cute.. that needs fixing
fixed upstream: commit c46f739dd39db3b07ab5deb4e3ec81e1c04a91af Author: Ingo Molnar <mingo@elte.hu> 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.
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.