> 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?
This archive was generated by hypermail 2b30 : Wed Jun 13 2001 - 16:03:45 PDT