Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: Buffer overflow prevention
From: Sam Baskinger <sam () reefedge com>
Date: Thu, 14 Aug 2003 11:19:03 -0400

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]