Messages in this thread | | | Date | Thu, 30 Dec 1999 21:14:16 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: Unexecutable Stack / Buffer Overflow Exploits... |
| |
Date: Thu, 30 Dec 1999 17:46:45 -0800 (PST) From: Dan Hollis <goemon@sasami.anime.net>
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/
| |