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]
Message-ID: <Pine.LNX.4.58.0607140148520.5906@dione>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ