Messages in this thread | | | Subject | Re: 2nd Linux kernel patch to remove stack exec | Date | Mon, 14 Apr 1997 13:15:06 -0600 | From | Warner Losh <> |
| |
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
| |