Full Disclosure mailing list archives
Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - simple workaround
From: Matthew Murphy <mattmurphy () kc rr com>
Date: Thu, 13 Jul 2006 20:13:12 -0500
Michal Zalewski wrote:
On Thu, 13 Jul 2006, Matthew Murphy wrote:setting 750 on /etc/cron.* would stop this exploitIncorrect. Did you even try this on ONE vulnerable box? The vulnerability exists BECAUSE the kernel doesn't enforce directory permissions when writing a core dump.You cannot chdir to (or access a file within) a directory to which you have no 'execute' permission. Cores are dumped in the current working directory of a process. You cannot make /etc/cron.* your working directory unless the aforementioned permission is given to you. The exploit works by doing a chdir to that directory as an user; if the directory is not accessible, this will fail, and the core will be dumped in elsewhere.
Hmm... I tried this on a Linux box graciously offered by a friend. He admits to "some really fucked up options" in his kernel compile, but...
the exploit worked as advertised with a 750 perm on /etc/cron.d. Who knows what's going on under the hood.
uname -a outputs: Linux [host] 2.6.13.4 #3 Tue Oct 18 21:05:09 EDT 2005 i686 GNU/LinuxIt would appear that you are correct about the permissions involved in this. I tried to repro it on another box by creating a directory, letting root "steal" it, setting it to 750 and then trying to coredump there. No dice.
So, I don't know what is up with the config of the first box, but it's obviously not... okay.
> The vulnerability still probably can be exploited by other means (mail > subsystem? logrotate? etc), but that probably pretty much solves the > crond vector. >
If your users actually have write permissions to /etc/cron.d, do the world a favor and disconnect from the internet as soon as humanly possible.You seem to be confused. Most systems do have a+rx permissions to /etc/cron.* directories, and that most certainly helps with that exploit.
I'm not confused -- you have a legitimate point. I just let an apparently b0rked test box convince me that the original poster's workaround was less than effective.
Though it does appear to block this on a *sane* config, there are, as you mention above, other vectors. That would be some pretty good work to exploit logrotate, but it seems possible at first glance.
So, I'd advise people to simply eliminate core dumps, as I did with the previous post on the subject:
echo 0 >/proc/sys/kernel/core_uses_pid echo /dev/null >/proc/sys/kernel/core_patternIf you're uncomfortable completely obliterating core dumps, use a dedicated "core dump directory" or create a directory structure with directories for each user and use the %u specifier in the core_pattern.
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t Exploit ( BID 18874 / CVE-2006-2451 ) Roman Medina-Heigl Hernandez (Jul 11)
- Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t Exploit ( BID 18874 / CVE-2006-2451 ) Ariel Biener (Jul 12)
- Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t Exploit ( BID 18874 / CVE-2006-2451 ) Ariel Biener (Jul 12)
- Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - simple workaround lars brun nielsen (Jul 13)
- Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - simple workaround Matthew Murphy (Jul 13)
- Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - simple workaround Michal Zalewski (Jul 13)
- Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - simple workaround Matthew Murphy (Jul 13)
- Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - simple workaround PERFECT . MATERIAL (Jul 13)
- Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - simple workaround Kyle Lutze (Jul 13)
- Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - simple workaround Jon Hart (Jul 14)
- Re: Linux Kernel 2.6.x PRCTL Core Dump Handling - simple workaround Matthew Murphy (Jul 13)