Buffer overflow prevention

From: Eygene A. Ryabinkin (rea_at_rea.mbslab.kiae.ru)
Date: 08/13/03

  • Next message: Nicholas Weaver: "Re: Buffer overflow prevention" 
    Date: Wed, 13 Aug 2003 14:28:33 +0400
To: bugtraq@securityfocus.com

      Hi!
     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

  • Next message: Nicholas Weaver: "Re: Buffer overflow prevention"

    Relevant Pages

    • Re: Buffer overflow prevention
      ... > I have an idea on buffer overflow prevention. ... > the fact that we're using the stack, referenced by SS:ESP pair, both ... > procedure return address and for local variables. ... if we use first segment for passing variables ...
      (Bugtraq)
    • RE: Buffer overflow prevention
      ... implement ProPolice stack protection. ... > I have an idea on buffer overflow prevention. ... > procedure return address and for local variables. ... > second segment only for local procedure variables, ...
      (Bugtraq)
    • Re: How to develop a random number generation device
      ... code, buffers, and stack sort of anywhere they like. ... It's up to the linker to build the segments, ... In many environments the segments end up in memory ... That's a common sort of buffer overflow (it's not the only one, ...
      (sci.electronics.design)
    • Re: Local variables controversial?
      ... >>>Calforth uses local variables, but doesn't set a policy of what's good ... they are implemented using a stack frame. ... is still on the Forth data stack? ...
      (comp.lang.forth)
    • Re: Local variables controversial?
      ... Calforth uses local variables, but doesn't set a policy of what's good ... of simply popping the old stack pointer off the stack frame and ... Do I understand you right to mean that the actual data in the stack frame is still on the Forth data stack? ...
      (comp.lang.forth)