[7524] in bugtraq
Re: A way to prevent buffer overflow exploits?
daemon@ATHENA.MIT.EDU (Crispin Cowan)
Wed Aug 5 12:23:36 1998
Date: Tue, 4 Aug 1998 10:12:56 -0700
Reply-To: Crispin Cowan <crispin@CSE.OGI.EDU>
From: Crispin Cowan <crispin@CSE.OGI.EDU>
To: BUGTRAQ@NETSPACE.ORG
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.370969E6@cse.ogi.edu>
Date: Thu, 30 Jul 1998 17:30:48 -0700
From: Crispin Cowan <crispin@cse.ogi.edu>
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" <jhardin@wolfenet.com>
CC: BUGTRAQ@NETSPACE.ORG
Subject: Re: A way to prevent buffer overflow exploits?
References: <Pine.LNX.3.96.980730164105.5019F-100000@gypsy.rubyriver.com>
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--
