On RedHat 9, gcc version 3.2.2 20030222, it is not included. [brian@WashingMachine brian]$ gcc -fstack-protector -o testfile testfile.c cc1: unrecognized option `-fstack-protector' -----Original Message----- From: Patrick Dolan [mailto:dolan@cc.admin.unt.edu] Sent: Wednesday, August 13, 2003 6:31 PM To: Lance James Subject: 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@bakbone.com> To: <dolan@cc.admin.unt.edu>; "'Eygene A. Ryabinkin'" <rea@rea.mbslab.kiae.ru> Cc: <bugtraq@securityfocus.com> 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@cc.admin.unt.edu] > 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 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 >
