full-disclosure - Linux Kernel 2.6.x PRCTL Core Dump Handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri Jul 14 02:14:04 2006
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Linux Kernel 2.6.x PRCTL Core Dump Handling
	- simple workaround

Michal Zalewski wrote:
> On Thu, 13 Jul 2006, Matthew Murphy wrote:
> 
>>> setting 750 on /etc/cron.* would stop this exploit
>> Incorrect.  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/Linux

It 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_pattern

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