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 for Android: free password hash cracker in your pocket

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

Date: Fri Jul 14 00:58:16 2006
From: lcamtuf at dione.ids.pl (Michal Zalewski)
Subject: Linux Kernel 2.6.x PRCTL Core Dump Handling
	- simple workaround

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.

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.

/mz