Re: Buffer overflow prevention

[Sam Baskinger <sam () reefedge com>]

-----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-----