Jan Jaeger writes:
> When we are talking about storing (ie overlaying) programs (trojans) on the
> stack space, then only hardware protection can really help. One would need
> to come to a model where instructions cannot be executed from the stack.
> One can achive this in S/390, by making the stack space a separate space,
> which is only addressable thru an access register (like an MVS data space).
> This way instructions can never be executed from the stack space, however, I
> am afraid that such an implementation would break a few things.
Solar Designer did a non-executable stack patch for Linux/ia32
(using segment protection for the stack space since ia32 page-level
protection does not distinguish read from execute). The things that
a non-executable stack break are mainly (1) gcc trampolines (used for
nested functions), (2) signal delivery and (3) application-specific
run-time code generation. He handled (1) and (2) by detecting such
code and disabling the non-exec stack on the fly (yes, this is a
slight exposure). For (3), he supported a an ELF executable marker
which disabled non-exec stack for the whole program.
It was fairly popular and worked well against the sort of attacks
which it was designed to prevent. Needless to say, people then worked
out how to do some exploits even with non-exec stack ("return into
libc" et al). The arms war continues, as always.
--Malcolm
--
Malcolm Beattie <[EMAIL PROTECTED]>
Linux Technical Consultant
IBM EMEA Enterprise Server Group...
...from home, speaking only for myself
