Re: Buffer overflow prevention

From: Patrick Dolan (dolan_at_cc.admin.unt.edu)
Date: 08/13/03

  • Next message: Frog Man: "BBCode XSS in XOOPS CMS" 
    To: "Eygene A. Ryabinkin" <rea@rea.mbslab.kiae.ru>
Date: Wed, 13 Aug 2003 13:20:03 -0500

    There is a flag for the Gnu C/C++ compilers, -fstack-protector, that will
    implement ProPolice stack protection. It should prevent stack smashing
    techniques.

    On Wednesday 13 August 2003 05:28 am, Eygene A. Ryabinkin wrote:
    > 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 

    -- 
Patrick Dolan
UNT Information Security
PGP ID: E5571154
Primary key fingerprint: 5681 25E4 6BE6 298E 9CF0  6F8D B13B 2456 E557 1154
  • Next message: Frog Man: "BBCode XSS in XOOPS CMS"

    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
      ... > based on the fact that we're using the stack, ... both for procedure return address and for local variables. ... if we use first segment for passing ... This only stops attacks which overwrite the return address pointers on ...
      (Bugtraq)
    • Re: shell code on minix
      ... compilers may be different. ... The stack segment in a i386 processor are not executable and analyzing in details the assembler generated in the Minix and Linux you may see what trick are used and why it works on Linux. ... Reading any book on the i386 family of processors would be of help to understand how memory protection and allocation works. ...
      (comp.os.minix)
    • 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: size_t in a struct
      ... code to make sure none of it depends on the Standard order. ... There are periodically reports that certain compilers ... gcc comes with the ``ProPolice'' stack protection exten- ... That talks about reordering local variables (which is perfectly ...
      (comp.lang.c)