[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Buffer overflow prevention
On Wednesday, Aug 13, 2003, at 03:28 US/Pacific, Eygene A. Ryabinkin
I have an idea on buffer overflow prevention. I doubt that it's new,
haven't seen an implementation of it in any freely distributable Un*x
So, I hardly need your comments on it.
Preliminary: I'm talking about Intel x86 architecture, but maybe it
applicable to others as well.
The idea itself: all (correct me if I'm wrong) buffer overflows are
the fact that we're using the stack, referenced by SS:ESP pair, both
procedure return address and for local variables. It seems to me, that
have two stacks -- one for real stack and one for variables -- it will
a bunch of problems. So, my suggestion: let us organise two segments:
normal stack, growing downwards, referenced by SS:ESP pair and the
for local variables, referenced by GS:EBP pair, with either upwards or
downwards growing. Now, if we use first segment for passing variables
procedure return addresses (normal stack usage), and second segment
local procedure variables, we will have the following advantages:
1) Local variables and return address will be physically (by means of
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
very often used for the stack frame.
Of course, this two segments can be made non-executable, just in case.
It's definitely good to be thinking of novel approaches to securing
code. Machines in the old days used to have memory partitioned in
similar fashions. But realize that overwriting return addresses via
stack trashing is only one way a program can be compromised.
C++ programs, for instance, have vtables, 'this' pointers, and all
sorts of other fun stuff that can be tinkered with - not to mention the
Approaches that involve partitioning executable code and data are
probably the easiest route. It becomes a major challenge to do
something interesting with return address manipulation when the memory
map is setup with execute-only in one range (for the code) and
non-executable (for stack & heap) in another. If you can't inject a
return address to the code of your choosing, than what's the point?
Dealing with dynamic code gets tricky (dynamic libs, Java, CLR, and
interpreters) in this environment. But it's quite do-able.
What we need to implement the idea: first, rewrite kernel to organise
segments for every process and to place proper values into the segment
registers upon the program startup. Second, rewrite the compiler to
the new scheme of local variables addresation. So, the changes are
in some sence.
As I said, I hardly need your criticism, suggestions, etc. of any
What fun is that? ;^)
Strongbox Network Services Inc.
mailto:craig .AT. strong-box.net
This message checked for dangerous content by MailScanner on StrongBox.