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-next>] [day] [month] [year] [list]

Date: Wed, 13 Aug 2003 16:21:02 -0700
From: Lance James <lance.james@...bone.com>
To: "'dolan@...admin.unt.edu'" <dolan@...admin.unt.edu>,
	"'Eygene A. Ryabinkin'" <rea@....mbslab.kiae.ru>
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