Home page logo
/

bugtraq logo Bugtraq mailing list archives

RE: Buffer overflow prevention
From: "Brian Glover" <brian () centurionservice com>
Date: Thu, 14 Aug 2003 13:36:47 -0500

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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]