[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Buffer overflow prevention
Yes, it should be in all distributions of GCC. I use it on a Gentoo Linux
server of mine. The version is 3.2.3, just FYI.
----- Original Message -----
From: "Lance James" <lance.james@xxxxxxxxxxx>
To: <dolan@xxxxxxxxxxxxxxxx>; "'Eygene A. Ryabinkin'"
Sent: Wednesday, August 13, 2003 6:21 PM
Subject: RE: Buffer overflow prevention
> Is that in universal gcc, or OpenBSD only?
> Lance James
> -----Original Message-----
> From: Patrick Dolan [mailto:dolan@xxxxxxxxxxxxxxxx]
> Sent: Wednesday, August 13, 2003 10:20 AM
> To: Eygene A. Ryabinkin
> Subject: Re: Buffer overflow prevention
> There is a flag for the Gnu C/C++ compilers, -fstack-protector, that will
> implement ProPolice stack protection. It should prevent stack smashing
> 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,
> > 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
> > be applicable to others as well.
> > The idea itself: all (correct me if I'm wrong) buffer overflows are
> > on 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
> > would we have two stacks -- one for real stack and one for variables --
> > 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
> > passing variables and procedure return addresses (normal stack usage),
> > 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
> > 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
> > 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 type.
> > rea
> Patrick Dolan
> UNT Information Security
> PGP ID: E5571154
> Primary key fingerprint: 5681 25E4 6BE6 298E 9CF0 6F8D B13B 2456 E557