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)
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)
Eygene A. Ryabinkin wrote:

> 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.
>...
> 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:
>
This is approximately what StackShield
<http://www.angelfire.com/sk/stackshield/info.html> does. However, it
does not appear to have been maintained since 2000.

Crispin

--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Chief Scientist, Immunix http://immunix.com
http://www.immunix.com/shop/

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus