Bugtraq mailing list archives
Re: Buffer overflow prevention
From: "Patrick Dolan" <dolan () cc admin unt edu>
Date: Wed, 13 Aug 2003 18:31:09 -0500
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
Ihaven'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, bothforprocedure 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 ofCPU)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 tosupportthe new scheme of local variables addresation. So, the changes areminimal,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
Current thread:
- Re: Buffer overflow prevention, (continued)
- Re: Buffer overflow prevention weigelt (Aug 15)
- Re: Buffer overflow prevention Jonathan A. Zdziarski (Aug 13)
- Re: Buffer overflow prevention Andreas Beck (Aug 14)
- Re: Buffer overflow prevention Jingmin (Jimmy) Zhou (Aug 13)
- Re: Buffer overflow prevention Craig Pratt (Aug 13)
- Re: Buffer overflow prevention Patrick Dolan (Aug 13)
- Re: Buffer overflow prevention Mariusz Woloszyn (Aug 14)
- Re: Buffer overflow prevention Crispin Cowan (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- RE: Buffer overflow prevention Lance James (Aug 14)
- Re: Buffer overflow prevention Patrick Dolan (Aug 14)
- Re: Buffer overflow prevention Jedi/Sector One (Aug 14)
- Re: Buffer overflow prevention Stephen Clowater (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- Re: Buffer overflow prevention Solar Designer (Aug 15)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- Re: Buffer overflow prevention Mariusz Woloszyn (Aug 14)
- Re: Buffer overflow prevention Theo de Raadt (Aug 14)
- Re: Buffer overflow prevention Matt D. Harris (Aug 14)
- Re: Buffer overflow prevention sauron (Aug 14)
- Re: Buffer overflow prevention Timo Sirainen (Aug 14)
- Re: Buffer overflow prevention Jedi/Sector One (Aug 14)
- Re: Buffer overflow prevention Theo de Raadt (Aug 14)
(Thread continues...)