aboutsummaryrefslogtreecommitdiff
path: root/init/do_mounts_md.c
diff options
context:
space:
mode:
authorMarcel Holtmann <marcel@holtmann.org>2006-07-12 13:12:00 +0200
committerLinus Torvalds <torvalds@g5.osdl.org>2006-07-12 12:50:25 -0700
commitabf75a5033d4da7b8a7e92321d74021d1fcfb502 (patch)
tree9d39bb9ac449232d4d8f196f2a83de7d5be681ff /init/do_mounts_md.c
parentb2d6744849b5bf6b4593b81c136772df7a238ac9 (diff)
[PATCH] Fix prctl privilege escalation and suid_dumpable (CVE-2006-2451)
Based on a patch from Ernie Petrides During security research, Red Hat discovered a behavioral flaw in core dump handling. A local user could create a program that would cause a core file to be dumped into a directory they would not normally have permissions to write to. This could lead to a denial of service (disk consumption), or allow the local user to gain root privileges. The prctl() system call should never allow to set "dumpable" to the value 2. Especially not for non-privileged users. This can be split into three cases: 1) running as root -- then core dumps will already be done as root, and so prctl(PR_SET_DUMPABLE, 2) is not useful 2) running as non-root w/setuid-to-root -- this is the debatable case 3) running as non-root w/setuid-to-non-root -- then you definitely do NOT want "dumpable" to get set to 2 because you have the privilege escalation vulnerability With case #2, the only potential usefulness is for a program that has designed to run with higher privilege (than the user invoking it) that wants to be able to create root-owned root-validated core dumps. This might be useful as a debugging aid, but would only be safe if the program had done a chdir() to a safe directory. There is no benefit to a production setuid-to-root utility, because it shouldn't be dumping core in the first place. If this is true, then the same debugging aid could also be accomplished with the "suid_dumpable" sysctl. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'init/do_mounts_md.c')
0 files changed, 0 insertions, 0 deletions