[19917] in bugtraq
Re: ptrace/execve race condition exploit (non brute-force)
daemon@ATHENA.MIT.EDU (Solar Designer)
Wed Mar 28 21:18:35 2001
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID: <20010328121856.A1539@openwall.com>
Date: Wed, 28 Mar 2001 12:18:56 +0400
Reply-To: Solar Designer <solar@OPENWALL.COM>
From: Solar Designer <solar@OPENWALL.COM>
X-To: Mariusz Woloszyn <emsi@IPARTNERS.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.04.10103280129160.455-200000@dzyngiel.ipartners.pl>;
from emsi@IPARTNERS.PL on Wed, Mar 28, 2001 at 01:32:15AM +0200
On Wed, Mar 28, 2001 at 01:32:15AM +0200, Mariusz Woloszyn wrote:
> Anyway: here is a fast way to fix the problem (but intoduces new one), the
> kernel module that disables ptrace syscall.
Don't forget that the race isn't only against ptrace. There's
procfs. Fortunately, get_task() in fs/proc/mem.c checks for
PF_PTRACED, so the worst ways of abuse via procfs are solved with
disabling ptrace. But it is not so obvious what other attacks
remain possible.
--
/sd
