Message-ID: <631ac1d90607131844p7a48f058k1f08ab28316d16bf@mail.gmail.com>
Date: Fri Jul 14 02:44:13 2006
From: perfect.material at gmail.com (PERFECT.MATERIAL)
Subject: Linux Kernel 2.6.x PRCTL Core Dump Handling -
	simple workaround

Dear Matt,

This is silly, you are a lying jigaboo. That is of course unless the machine
you tested on was compiled with the
CONFIG_ALLOW_MATT_MURPHY_TO_RUN_HIS_MOUTH_AND_CHDIR_INTO_NON_EXECUTABLE_DIRECTORIES
option. This option hasn't been on by default in any distribution since
Redhat 6.2 as far as I can tell.

Get your facts straight you wacky gook, regardless of the configuration of
this magical test machine, you have proven you do not understand Linux file
permissions. This is fine, just keep it to yourself and don't get all Kikey
Evron about it.

PERFECT.MATERIAL


On 7/13/06, Matthew Murphy <mattmurphy@...rr.com> wrote:
>
> 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.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060713/ab1a6a51/attachment.html

Powered by blists - more mailing lists