[21007] in bugtraq
Re: Announcing RSX - non exec stack/heap module
daemon@ATHENA.MIT.EDU (zen-parse@gmx.net)
Wed Jun 13 19:03:27 2001
Date: Wed, 13 Jun 2001 22:40:06 +1200 (NZST)
From: <zen-parse@gmx.net>
To: <bugtraq@securityfocus.com>
In-Reply-To: <Pine.LNX.4.33.0106132214130.22121-100000@clarity.local>
Message-ID: <Pine.LNX.4.33.0106132217390.22172-100000@clarity.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> So now assume we doesn't link the libc-plt to the real libc location -
> instead we link it to a intermediate random glue code piece. The
> protection arises from the fact that it is hard to guess the location of
> this intermediate glue segment (and it is hard to guess the real libc
> vma too). So the attacker neither easily jump into some offset (skipping
> the ret checking code) in the glue code, nor directly jump into some
> real libc function. The addresses of the glue code and libc should
> change with every execve() and fork() (to prevent binary search...).
What about /proc/$$/maps ?
pr--r--r-- 1 root root 0 Jun 13 22:18 /proc/21156/maps|
I suppose this could be made to lie, or just not be readable by other.
I haven't actually been following this, so I may have missed something...
but just a thought about how to maybe beat that?
