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)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It sounds like array bounds checking would offer an almost equivalent effect.
This would not stop mis-casting a struct and referencing out of it or similar
casting+address calcuation errors. To prevent that you would need either a
language that prevented the production of that sort of code or to solve the
halting problem.

Sam

On Wednesday 13 August 2003 15:28, Michal Zalewski wrote:
> On Wed, 13 Aug 2003, Eygene A. Ryabinkin wrote:
>
> [ BUGTRAQ is probably not the best place for such a discussion, but
> I'm not sure SECPROG is still alive and kicking, so... ]
>
> > I have an idea on buffer overflow prevention.
>
> Well, no, strictly speaking, you don't =) You have an idea for preventing
> one of the symptoms, which is eip overwrite. Overwriting other stack
> variables, pointers and flags in particular, or causing overflows
> elsewhere in the memory would still be as lethal. But I'm too picky... to
> the point.
>
> The concept itself isn't particularly new, but I think that prior takes on
> it considered splitting the call/ret and parameter stacks, instead of
> local variables vs everything else. The latter is indeed a neat idea,
> because it does not require major changes to the entire system at once -
> the calling convention remains the same.
>
> For a lesser performance impact, you should just keep arrays and alloca()
> buffers in the secondary stack, I think. Since you need to modify the
> compiler anyway, I think it's a wiser decision than putting everything on
> the secondary stack. Besides, by keeping single integers (often used for
> flags or to keep other vital parameters) and pointers away from the
> buffers, you make it in some cases more difficult to take over the
> application.
>
> It has an advantage over non-executable stack patch, address randomization
> or stack canaries in that it prevents ret address manipulation altogether,
> making it impossible to return into PLT, program code, libc or whatnot, so
> it's a nice idea.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/O6hnuabcSIn58XwRAq+SAKCMTe4s2IzK2vkFO6GOsuUGgxWWFACdHUhw
F3+KlhvZTSJy2lPvt31ueHs=
=YgjX
-----END PGP SIGNATURE-----

[ reply ]
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)


 

Privacy Statement
Copyright 2010, SecurityFocus