Re: Buffer overflow prevention

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.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [
http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2003-08-13 21:14 --