On Thu, 30 Dec 1999, Theodore Y. Ts'o wrote:
> In any case, I suspect that if something randomly added some random
> value between 0 and 128k to the stack pointer at startup time, it would
> also go a fairly long way towards thwarting overrun attacks --- but make
> no mistake, it's still only papering over the problem.
But is "it wont work 100% of the time" a good enough reason to discard the
idea out of hand entirely? The fact we cant raise the bar infinitely high
means we shouldnt raise it even a little?
It's a question of benefits and costs, and how you value the code
complexity, long-term maintainability of the code, potential to
incovenience legitimate programs etc. Different people will have
different opinions about how to balanace the benefits and the costs.
What I've tried to do is point out other solutions that have slightly
different benefits and costs --- for example, from having libc map out
the stack frames and avoid memory copies that violate the stack frame
boundaries, to simply moving the stack around. (Taking a page for Solar
Designer's ideas, why not just simply move the stack so that there's a
0x00 byte in the stack address, say, in a relatively high nibble. This
makes it a lot harder for programs to be able to deposite the correct
return address using ovrrun data.)
Kernel mods to make the stack executable *aren't* the only way to try to
prevent stack smashes from becoming security holes. There _are_ other
potential approaches. Are they perfect? No. But neither is making the
stack non-executable; everyone admits that. Furthermore, some of these
alternatives have the property that don't require making ugly kernel
changes. That should make them at least passingly interesting.
- Ted
-
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/