Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Feb 1997 04:54:35 -0500 (EST)
From:      Peter Dufault <dufault@hda.com>
To:        roberto@keltia.freenix.fr (Ollivier Robert)
Cc:        freebsd-security@freebsd.org
Subject:   Re: buffer overruns
Message-ID:  <199702100954.EAA08773@hda.hda.com>
In-Reply-To: <19970209231433.QS19404@keltia.freenix.fr> from Ollivier Robert at "Feb 9, 97 11:14:33 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> The easiest way to close all this bugs is to make the stack non executable
> (from a processor standpoint) but I'm not sure you can do it in Intel
> processors.

Is the stack executable?  I've been assuming the exploits modify
the stack to return to a built up call to "system" or something
else in the library with their own args setup.  I've been assuming
that executing data isn't part of modern exploits.

Has anyone seen modifications to gcc to generate guard bands around
automatics and stack check sequences?  The automatics can be checked
when they come into / go out of existence, and stack integrity at
return time.  It won't stop the exploits, but it will make them
harder, and you will get "security" dumps from setuid programs if
you require that setuid programs be compiled that way (and linked
against a separate "secure" library compiled that way also).
You could even hack things so that setuid would fail for
"insecure" executables.

The idea is simple enough that someone must have tried it.

-- 
Peter Dufault (dufault@hda.com)   Realtime Machine Control and Simulation
HD Associates, Inc.               Voice: 508 433 6936



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702100954.EAA08773>