[11785] in bugtraq
Re: Stack Shield: defending from "stack smashing" attacks
daemon@ATHENA.MIT.EDU (Crispin Cowan)
Thu Sep 9 13:48:28 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <37D20678.CE18860E@cse.ogi.edu>
Date: Sun, 5 Sep 1999 05:58:16 +0000
Reply-To: crispin@CSE.OGI.EDU
From: Crispin Cowan <crispin@CSE.OGI.EDU>
X-To: Chris Keane <Chris.Keane@COMLAB.OX.AC.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
Chris Keane wrote:
> >>>>> On Tue, 31 Aug 1999, "CC" = Crispin Cowan wrote:
> +> So, why would one use the approach of saving the return address on
> +> another stack, instead of patching the stack itself, like StackGuard?
> +> The only reason I can imagine, is that one does not want to change the
> +> stack layout. The benefit of not changing the stack layout, is that
> +> you can do the change outside of the compiler.
> CC> Another major advantage is that gdb continues to work. The
> CC> StackGuard method fails for all programs that introspect the stack,
> CC> gdb being the major example.
> And presumably it would mean you could compile kernels with it, which also
> fails with StackGuard (for Linux, at least).
Part of why we never bothered to make StackGuard work for kernels is that it
is unclear what value it adds. At best, you could panic() the kernel.
Admitedly, that's better than yielding control to the attacker, but it is much
more disruptive than killing processes. I also observe that there are *very*
fiew kernel buffer overflow exploits. It's as if kernel hackers are better
than the rest ... :-)
Crispin
-----
Crispin Cowan, Research Assistant Professor of Computer Science, OGI
NEW: Protect Your Linux Host with StackGuard'd Programs :FREE
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
