> 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?
