Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: Buffer overflow prevention
From: Sam Baskinger (samreefedge.com)
Date: Thu Aug 14 2003 - 10:19:03 CDT
-----BEGIN PGP SIGNED MESSAGE-----
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
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
> 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)
-----END PGP SIGNATURE-----