BugTraq
Buffer overflow prevention Aug 13 2003 10:28AM
Eygene A. Ryabinkin (rea rea mbslab kiae ru) (7 replies)
Re: Buffer overflow prevention Aug 13 2003 07:28PM
Michal Zalewski (lcamtuf coredump cx) (1 replies)
Re: Buffer overflow prevention Aug 14 2003 03:19PM
Sam Baskinger (sam reefedge com) (2 replies)
Re: Buffer overflow prevention Aug 14 2003 10:42PM
Crispin Cowan (crispin immunix com)
Re: Buffer overflow prevention Aug 14 2003 09:48PM
weigelt metux de
Re: Buffer overflow prevention Aug 13 2003 07:13PM
Nicholas Weaver (nweaver CS berkeley edu) (1 replies)
Re: Buffer overflow prevention Aug 13 2003 07:23PM
weigelt metux de (1 replies)
Re: Buffer overflow prevention Aug 13 2003 09:26PM
Michal Zalewski (lcamtuf coredump cx)
Re: Buffer overflow prevention Aug 13 2003 06:40PM
Craig Pratt (craig strong-box net)
Re: Buffer overflow prevention Aug 13 2003 06:26PM
Jonathan A. Zdziarski (jonathan networkdweebs com) (1 replies)
Re: Buffer overflow prevention Aug 13 2003 11:03PM
Andreas Beck (becka uni-duesseldorf de)
Re: Buffer overflow prevention Aug 13 2003 06:20PM
Patrick Dolan (dolan cc admin unt edu) (2 replies)
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

[ reply ]
Re: Buffer overflow prevention Aug 14 2003 09:44AM
Mariusz Woloszyn (emsi ipartners pl)
Re: Buffer overflow prevention Aug 13 2003 11:33PM
Crispin Cowan (crispin immunix com) (1 replies)
Re: Buffer overflow prevention Aug 15 2003 08:32AM
Peter Busser (peter trusteddebian org)
Re: Buffer overflow prevention Aug 13 2003 06:18PM
Jingmin (Jimmy) Zhou (jimmy mtc dhs org)
Re: Buffer overflow prevention Aug 13 2003 06:12PM
Crispin Cowan (crispin immunix com)


 

Privacy Statement
Copyright 2010, SecurityFocus