Bugtraq mailing list archives
Re: Buffer overflow prevention
From: Craig Pratt <craig () strong-box net>
Date: Wed, 13 Aug 2003 11:40:40 -0700
On Wednesday, Aug 13, 2003, at 03:28 US/Pacific, Eygene A. Ryabinkin wrote:
Hi!I have an idea on buffer overflow prevention. I doubt that it's new, but I haven't seen an implementation of it in any freely distributable Un*x system.So, I hardly need your comments on it.Preliminary: I'm talking about Intel x86 architecture, but maybe it will beapplicable to others as well.The idea itself: all (correct me if I'm wrong) buffer overflows are based on the fact that we're using the stack, referenced by SS:ESP pair, both for procedure return address and for local variables. It seems to me, that would we have two stacks -- one for real stack and one for variables -- it will solve a bunch of problems. So, my suggestion: let us organise two segments: one for normal stack, growing downwards, referenced by SS:ESP pair and the second one,for local variables, referenced by GS:EBP pair, with either upwards ordownwards growing. Now, if we use first segment for passing variables and procedure return addresses (normal stack usage), and second segment only forlocal procedure variables, we will have the following advantages:1) Local variables and return address will be physically (by means of CPU)divided and it will not be possible to touch the return address by overflowing local buffer.2) The procedure introduces only one extra register -- GS, since EBP isvery often used for the stack frame. Of course, this two segments can be made non-executable, just in case.
It's definitely good to be thinking of novel approaches to securing code. Machines in the old days used to have memory partitioned in similar fashions. But realize that overwriting return addresses via stack trashing is only one way a program can be compromised.
C++ programs, for instance, have vtables, 'this' pointers, and all sorts of other fun stuff that can be tinkered with - not to mention the heap.
Approaches that involve partitioning executable code and data are probably the easiest route. It becomes a major challenge to do something interesting with return address manipulation when the memory map is setup with execute-only in one range (for the code) and non-executable (for stack & heap) in another. If you can't inject a return address to the code of your choosing, than what's the point?
Dealing with dynamic code gets tricky (dynamic libs, Java, CLR, and interpreters) in this environment. But it's quite do-able.
What we need to implement the idea: first, rewrite kernel to organise twosegments for every process and to place proper values into the segmentregisters upon the program startup. Second, rewrite the compiler to support the new scheme of local variables addresation. So, the changes are minimal,in some sence.As I said, I hardly need your criticism, suggestions, etc. of any type.rea
What fun is that? ;^) Craig -- Craig Pratt Strongbox Network Services Inc. mailto:craig .AT. strong-box.net -- This message checked for dangerous content by MailScanner on StrongBox.
Current thread:
- Re: Buffer overflow prevention, (continued)
- 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)
- RE: Buffer overflow prevention Lance James (Aug 14)
- Re: Buffer overflow prevention Patrick Dolan (Aug 14)
- Re: Buffer overflow prevention Jedi/Sector One (Aug 14)
- Re: Buffer overflow prevention Stephen Clowater (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- Re: Buffer overflow prevention Solar Designer (Aug 15)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
(Thread continues...)