Re: 2nd Linux kernel patch to remove stack exec
Warner Losh (imp@village.org)
Mon, 14 Apr 1997 13:15:06 -0600
In message <199704131906.QAA06271@sun1.ideal.ru> Solar Designer writes:
: About GCC trampolines -- yes, there is a problem, but in reality it turns
: out to be quite easy to solve; also, nested functions, and especially
: those which address gets passed somewhere else, are not common in real
: world applications -- one of the reasons is that it's a GNU C extension.
: Since most programs will never use the trampolines, it makes sense to run
: them with non-executable stack, and enable stack execution permission for
: those that really need it. This can be done automatically, by modifying
: the GPF handler to switch back to the huge code segment (which covers the
: stack) and re-executing the instruction, unless it was a RET. Since most
: buffer overflows can only be exploited by overwriting the return address,
: this will still make them unexploitable (RET has to be the instruction to
: pass the control onto the stack), while C programs will normally only use
: CALL, and it is extremely unlikely that some code will use RET for that
: purpose (this can never happen for pure C programs compiled with GCC).
: Note that such emulation won't make the things run any slower since only
: one GPF per entire process life may get generated (after that the stack
: remains executable for this entire process).
There is a fatal flaw in this. All I have to do is send the process
one signal, and then I can take advantage of a stack overflow. Or the
process just has to generate one signal and keep going. This is a
very common occurrance. For example, in ftpd I can cause it to do a
signal by sending it urgent data. If there were then an exploitable
buffer overflow down stream, I could now make use of that buffer
overflow to get in.
Warner