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>