bugtraq - Re: Buffer overflow prevention

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 13 Aug 2003 18:31:09 -0500
From: "Patrick Dolan" <dolan@...admin.unt.edu>
To: "Lance James" <lance.james@...bone.com>
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
>