|
BugTraq
Buffer overflow prevention Aug 13 2003 10:28AM Eygene A. Ryabinkin (rea rea mbslab kiae ru) (7 replies) Re: Buffer overflow prevention Aug 13 2003 07:28PM Michal Zalewski (lcamtuf coredump cx) (1 replies) Re: Buffer overflow prevention Aug 13 2003 07:13PM Nicholas Weaver (nweaver CS berkeley edu) (1 replies) Re: Buffer overflow prevention Aug 13 2003 06:26PM Jonathan A. Zdziarski (jonathan networkdweebs com) (1 replies) Re: Buffer overflow prevention Aug 13 2003 06:20PM Patrick Dolan (dolan cc admin unt edu) (2 replies) |
|
Privacy Statement |
I have an idea on buffer overflow prevention. I doubt that it's new, but I
haven't seen an implementation of it in any freely distributable Un*x system.
So, I hardly need your comments on it.
Preliminary: I'm talking about Intel x86 architecture, but maybe it will be
applicable to others as well.
The idea itself: all (correct me if I'm wrong) buffer overflows are based on
the fact that we're using the stack, referenced by SS:ESP pair, both for
procedure return address and for local variables. It seems to me, that would we
have two stacks -- one for real stack and one for variables -- it will solve
a bunch of problems. So, my suggestion: let us organise two segments: one for
normal stack, growing downwards, referenced by SS:ESP pair and the second one,
for local variables, referenced by GS:EBP pair, with either upwards or
downwards growing. Now, if we use first segment for passing variables and
procedure return addresses (normal stack usage), and second segment only for
local procedure variables, we will have the following advantages:
1) Local variables and return address will be physically (by means of CPU)
divided and it will not be possible to touch the return address by
overflowing local buffer.
2) The procedure introduces only one extra register -- GS, since EBP is
very often used for the stack frame.
Of course, this two segments can be made non-executable, just in case.
What we need to implement the idea: first, rewrite kernel to organise two
segments for every process and to place proper values into the segment
registers upon the program startup. Second, rewrite the compiler to support
the new scheme of local variables addresation. So, the changes are minimal,
in some sence.
As I said, I hardly need your criticism, suggestions, etc. of any type.
rea
[ reply ]