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] [day] [month] [year] [list]

Message-ID: <20060714164916.GA24509@spoofed.org>
Date: Fri Jul 14 17:49:49 2006
From: jhart at spoofed.org (Jon Hart)
Subject: Linux Kernel 2.6.x PRCTL Core Dump Handling -
	simple workaround

On Thu, Jul 13, 2006 at 09:57:05PM -0700, Kyle Lutze wrote:
> it seems that this relies on /etc/cron.d being there? or is it specific
> to a crond? I use fcron which doesn't use /etc/cron.d and I have been
> unable to get the exploit to successfully work. 2.6.14 kernel
> 
> sh: /tmp/sh: No such file or directory
> 
> I'm running gentoo-sources without selinux or anything else special for
> security. I tried changing it to cron.daily just to test and that
> doesn't work either.

This particular vulnerability allows you to write core files as root in
any directory that you have permission to be in.  This particular
*exploit* works by arranging the code such that when the core dump
happens, a valid cron entry will appear in the dump and, in turn, get
executed as root within the next minute when crond scans /etc/cron.d for
jobs.

Think of exploiting this vulnerablity this way -- you can write a file
as root in any directory that you have permission to chdir to.  The
contents are not totally controlled by you, but you do have fairly good
control over certain portions of that file. Furthermore, you do not have
control over the filename.  Get creative.

Looking at fcron, I'm not sure there is a way to leverage this
vulnerability to gain root, though I could be wrong.

Other ways of exploiting this?  /etc/logrotate.d (logrotate), perhaps...

-jon