[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Buffer overflow prevention
On Wed, Aug 13, 2003 at 02:28:33PM +0400, Eygene A. Ryabinkin composed:
> 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.
Then why post this to a public list? Sorry, you are going to get
> 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.
On the x86, introducing ONE extra reserved register into the calling
convention is a performance killer: the ISA is far too register poor
> 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.
This only stops attacks which overwrite the return address pointers on
the stack, it doesn't stop heap overflows or other control-flow
As such, it seems like this only stops the same class of attacks which
StackGuard-style checking halts: manipulation of the return address
pointer through data overflows.
Since stackguard-techniques already exist, are very mature, and is
included as "On By Default" on OpenBSD and potentially on other
platforms (including possibly Windows, it is in Microsoft's latest
compiler and I think that all new code from Microsoft turns on this
compiler flag ), there is no sense inventing new structures, which
require substantially more changes to the infrastructure, which don't
offer any more protection.
 If microsoft doesn't have this flag turn on on their own products,
this would be a lawsuit waiting to happen.
Nicholas C. Weaver nweaver@xxxxxxxxxxxxxxx