lamont@icopyright.com wrote in part:
> The fact is that this doesn't offer much more than a speedbump. It
> doesn't prevent you from jumping around to arbitrary locations in memory,
> and there will almost always be something useful to you in libc or in the
> PLT. If system() is in the PLT then you've got a straight-forwards
> exploit. Otherwise look for something like strcpy() and copy your
> shellcode into the GOT or another rwx page and then jump there. You don't
> need an executable stack.
I accept this. But Ted Ts'o's [sp?] suggestion of a randomized
stack start does add some protection. At least it will take quite
a few logged tries before the exploit gets in.
> Libsafe[2] or Stackguard[3] provide better (although still not
> perfect) protection. I recommend reading the Libsafe white paper since it
> touches on the non-exec-stack issues and references a linux-kernel post
> from linus w.r.t why such a patch will not be accepted in the kernel.
>
> [1] http://www.openwall.com/
> [2] http://www.bell-labs.com/org/11356/libsafe.html
> [3] http://www.immunix.org/
Thanks for the references. I agree it is really up to the apps
to be secure. I thought I had found some specific ways the OS
might help, but they turned out rather lame.
But getting the apps secure runs counter to alot of `c` teaching
I learned [and forgot] many moons ago: avoid globals & statics,
maximize locals, avoid fixed length [anything] for maximum flexibility.
These very lessons will have to be unlearned to make secure apps.
Not easy. And [g]libc may also be infested.
-- Robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:19 EST