This is a multi-part message in MIME format. --------------F4EFF234B7C5BE54FCC35262 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Another repost: John D. Hardin wrote: > On Thu, 30 Jul 1998, Crispin Cowan wrote: > > John D. Hardin wrote: > > > 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. > > We considered this approach when we were designing StackGuard ( > > http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ ) but rejected it > > for the following reasons: > > * breaks compatibility with existing libraries > > Oh? Why would function A() care about where function B() stores its local > variables? All of the functions you call have to (more or less) respect the same calling conventions. In particular, all functions must agree on whether the caller or the callee saves registers, and which registers get used. If A() is reserving a particular register as the alternate stack pointer, and B() blows that register away without saving it, then you have a problem. > If you're speaking about communicating where the second stack *is*, I can > see your point - it would probably take some fancy gymnastics to propagate > the "second stack pointer" (if we even wish to have such a thing) around > library functions that were compiled without this option. Exactly. We discarded the 2nd stack idea because it's hard to do, and we found something equally effective that is easier to do: stack integrity checks. Crispin ----- Crispin Cowan, Research Assistant Professor of Computer Science, OGI StackGuard: protect your software against Stack Smashing Attack http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ Support Justice: Boycott Windows 98 --------------F4EFF234B7C5BE54FCC35262 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <35C11038.370969E6at_private> Date: Thu, 30 Jul 1998 17:30:48 -0700 From: Crispin Cowan <crispinat_private> Organization: Oregon Graduate Institute X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: "John D. Hardin" <jhardinat_private> CC: BUGTRAQat_private Subject: Re: A way to prevent buffer overflow exploits? References: <Pine.LNX.3.96.980730164105.5019F-100000at_private> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John D. Hardin wrote: > On Thu, 30 Jul 1998, Crispin Cowan wrote: > > John D. Hardin wrote: > > > 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. > > We considered this approach when we were designing StackGuard ( > > http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ ) but rejected it > > for the following reasons: > > * breaks compatibility with existing libraries > > Oh? Why would function A() care about where function B() stores its local > variables? All of the functions you call have to (more or less) respect the same calling conventions. In particular, all functions must agree on whether the caller or the callee saves registers, and which registers get used. If A() is reserving a particular register as the alternate stack pointer, and B() blows that register away without saving it, then you have a problem. > If you're speaking about communicating where the second stack *is*, I can > see your point - it would probably take some fancy gymnastics to propagate > the "second stack pointer" (if we even wish to have such a thing) around > library functions that were compiled without this option. Exactly. We discarded the 2nd stack idea because it's hard to do, and we found something equally effective that is easier to do: stack integrity checks. Crispin ----- Crispin Cowan, Research Assistant Professor of Computer Science, OGI StackGuard: protect your software against Stack Smashing Attack http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ Support Justice: Boycott Windows 98 --------------F4EFF234B7C5BE54FCC35262--
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:11:19 PDT