Message-ID: <CFE49B6D88ABF94D95723F2B213FAA08086ACA@centurion.centurionservice.com>
Date: Thu, 14 Aug 2003 13:36:47 -0500
From: "Brian Glover" <brian@...turionservice.com>
To: "Patrick Dolan" <dolan@...admin.unt.edu>
Subject: RE: Buffer overflow prevention


On RedHat 9, gcc version 3.2.2 20030222, it is not included.

[brian@...hingMachine brian]$ gcc -fstack-protector -o testfile
testfile.c 
cc1: unrecognized option `-fstack-protector'

-----Original Message-----
From: Patrick Dolan [mailto:dolan@...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@...bone.com>
To: <dolan@...admin.unt.edu>; "'Eygene A. Ryabinkin'"
<rea@....mbslab.kiae.ru>
Cc: <bugtraq@...urityfocus.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@...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
>

Powered by blists - more mailing lists