Bugtraq mailing list archives
Re: Smashing the Stack: prevention?
From: scoleman () SEWP NASA GOV (Steve Coleman - SEWP)
Date: Mon, 28 Apr 1997 10:33:47 -0400
Excerpts from what nate said: |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
Current thread:
- Access control on W3C httpd server, (continued)
- Access control on W3C httpd server Peter Lord (Apr 30)
- vulnerabilities in kerberos David Sacerdote (Apr 29)
- Sun Security Bulletin #00139 Sun Security Coordination Team (Apr 29)
- SMASHING THE STACK: PREVENTION? massimo at vnet.ibm.com (Apr 28)
- Re: SMASHING THE STACK: PREVENTION? Alex Belits (Apr 28)
- Re: SMASHING THE STACK: PREVENTION? Thomas H. Ptacek (Apr 29)
- Re: Smashing the Stack: prevention? Tim Newsham (Apr 27)
- Re: Smashing the Stack: prevention? Joe Zbiciak (Apr 28)
- Re: Smashing the Stack: prevention? Daniel Ryde (Apr 28)
- xlock clarification.... David Hedley (Apr 28)
- Re: Smashing the Stack: prevention? Steve Coleman - SEWP (Apr 28)
- Re: Smashing the Stack: prevention? Alexander Snarskii (Apr 28)
- Re: Smashing the Stack: prevention? Michael Shields (Apr 28)
- Re: Smashing the Stack: prevention? Theo de Raadt (Apr 28)
- Re: Smashing the Stack: prevention? Shawn Instenes (Apr 29)
- Re: Smashing the Stack: prevention? J.R.Valverde (Apr 28)
- Re: Smashing the Stack: prevention? Randal Schwartz (Apr 28)
- Re: Smashing the Stack: prevention? Thomas H. Ptacek (Apr 29)
- Re: Smashing the Stack: prevention? J.R.Valverde (Apr 29)
- Re: Smashing the Stack: prevention? J.R.Valverde (Apr 29)