|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: A way to prevent buffer overflow exploits?
Peter Jeremy (peter.jeremy
AUSS2.ALCATEL.COM.AU)Tue, 4 Aug 1998 14:05:38 +1000
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Logic Man: "Object tag and stack overflow on IE 4.0"
- Previous message: Pierre Beyssac: "[pb: Re: A way to prevent buffer overflow exploits? (was: "Any"
On Fri, 31 Jul 1998 05:07:14 +1000, Warner Losh <impvillage.org> wrote: >In message <98Jul30.074943est.40326
border.alcanet.com.au> Peter Jeremy writes: >: I wonder how feasible it would be to modify GCC to generate code with two >: stacks (or something equivalent): one for local variables, the other for >: parameters and return addresses. As a point of clarification, that was actually written by "John D. Hardin" <jhardin
WOLFENET.COM>. >Foreach function on function entry save the return location and bump a >pointer. This is effectively a second stack. However, no additional >support is needed from the kernel, Something needs to manage what happens when this array of saved return addresses (__global_return_ptr in the sample code) fills up. The sample code has no checks for this. Under a typical Un*x OS, you just keep pushing data onto the stack. When you reach the end of the allocated stack, the process gets a page fault (or similar). The kernel allocates another page of memory for the stack and the process continues obliviously. This sort of functionality needs to be provided for any `second stack' approach - either within the kernel, or using a SIGSEGV (or similar) handler. >Having kernel support for two stacks (esp for code, ebp for data) >would be interesting, but the code generation might be impacted more, >since ebp is generally referenced with both + and - args for locals >and parameters respectively. I don't think so. From some back-of-envelope scribbles, the changes are fairly trivial. The compiler just needs to build a local variable frame based on the old frame pointer instead of the spack pointer. If the parameters are passed on the same stack as local variables, the function calling code needs to push parameters via the frame pointer instead of the stack pointer. Peter -- Peter Jeremy (VK2PJ) peter.jeremy
alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247
- Next message: Logic Man: "Object tag and stack overflow on IE 4.0"
- Previous message: Pierre Beyssac: "[pb: Re: A way to prevent buffer overflow exploits? (was: "Any"