Bugtraq mailing list archives
Re: Announcing RSX - non exec stack/heap module
From: <zen-parse () gmx net>
Date: Wed, 13 Jun 2001 22:40:06 +1200 (NZST)
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?
Current thread:
- Announcing RSX - non exec stack/heap module Paul Starzetz (Jun 06)
- Re: Announcing RSX - non exec stack/heap module Crispin Cowan (Jun 06)
- Re: Announcing RSX - non exec stack/heap module Thomas Dullien (Jun 07)
- Re: Announcing RSX - non exec stack/heap module Paul Starzetz (Jun 07)
- Re: Announcing RSX - non exec stack/heap module Paul Starzetz (Jun 07)
- Re: Announcing RSX - non exec stack/heap module Crispin Cowan (Jun 07)
- Re: Announcing RSX - non exec stack/heap module Paul Starzetz (Jun 12)
- Re: Announcing RSX - non exec stack/heap module Crispin Cowan (Jun 13)
- Re: Announcing RSX - non exec stack/heap module Paul Starzetz (Jun 13)
- Re: Announcing RSX - non exec stack/heap module Thomas Dullien (Jun 07)
- Re: Announcing RSX - non exec stack/heap module Crispin Cowan (Jun 06)
- <Possible follow-ups>
- Re: Announcing RSX - non exec stack/heap module zen-parse (Jun 13)