|1. 'you gotta change the code'
| This one is obvious; people must change their SUID programs'
|source code to avoid nasty things like gets() sprintf() strcat() and
|strcpy() using things like fgets() strncat() strncpy() as substitutes.
This one seems an obvious solution but we need a way to automate the process
of detecting improper usage (see below).
|2. 'hmm. what if you change the compiler?'
| C compilers could be modified to do bounds checking, and/or
|problem functions could be made to complain to the user at compile time.
| After such modifications to the compiler, the resulting code
|is slower (which makes sense, because it now has to do a lot more to
|look after itself)
I personally would like a compile time option that would warn of any 'problem'
functions operating on storage class type "auto" members. This way I could
pull down something off the web and compile it and have it point out where the
code might need further inspection. This would incurr more cpu cycles during
compilation and perhapse an updateable list of 'problem' functions, but would
remain efficient during runtime.
|3. 'ok, what about the CPU/OS kernel stack exec permission?'
| What about stopping the buffer overflow problem at the kernel
|level? This might mean that you wouldn't have to inspect thousands of
|lines of code, rebuild gcc, or recompile anything except the kernel.
|Sounds nice, doesn't it.. well...
Even if the stack is not executable this does not mean that one can not play
games with the stack frames on some OS's and use the side effects to either
return us to sections of code where we never came from and/or with values on
the stack that the program never set. Granted this is more difficult but not
impossible for a determined hacker.
Steve Coleman -- scoleman@sewp.nasa.gov
vox: 301.286.7636 fax: 301.286.0317