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-----
Current thread:
- Buffer overflow prevention Eygene A. Ryabinkin (Aug 13)
- Re: Buffer overflow prevention Nicholas Weaver (Aug 13)
- Re: Buffer overflow prevention weigelt (Aug 13)
- Re: Buffer overflow prevention Michal Zalewski (Aug 13)
- Re: Buffer overflow prevention weigelt (Aug 13)
- Re: Buffer overflow prevention Crispin Cowan (Aug 13)
- Re: Buffer overflow prevention Michal Zalewski (Aug 13)
- Re: Buffer overflow prevention Sam Baskinger (Aug 14)
- Re: Buffer overflow prevention Crispin Cowan (Aug 15)
- Re: Buffer overflow prevention weigelt (Aug 15)
- Re: Buffer overflow prevention Sam Baskinger (Aug 14)
- Re: Buffer overflow prevention Jonathan A. Zdziarski (Aug 13)
- Re: Buffer overflow prevention Andreas Beck (Aug 14)
- Re: Buffer overflow prevention Jingmin (Jimmy) Zhou (Aug 13)
- Re: Buffer overflow prevention Craig Pratt (Aug 13)
- Re: Buffer overflow prevention Patrick Dolan (Aug 13)
- Re: Buffer overflow prevention Mariusz Woloszyn (Aug 14)
- Re: Buffer overflow prevention Crispin Cowan (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
(Thread continues...)
- Re: Buffer overflow prevention Nicholas Weaver (Aug 13)