Bug 3043 - issue with core dump owner
Summary: issue with core dump owner
Status: CLOSED CODE_FIX
Alias: None
Product: Process Management
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Ingo Molnar
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-10 19:15 UTC by blake frantz
Modified: 2010-08-16 07:46 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.x and 2.4.x
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

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

Note You need to log in before you can comment on or make changes to this bug.