[4367] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Smashing the Stack: prevention?

daemon@ATHENA.MIT.EDU (Michael Shields)
Tue Apr 29 00:12:50 1997

Date: 	Mon, 28 Apr 1997 19:38:33 -0000
Reply-To: Michael Shields <shields@CROSSLINK.NET>
From: Michael Shields <shields@CROSSLINK.NET>
X-To:         nate <nate@MILLCOMM.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <Pine.LNX.3.95.970427164308.1982A-100000@amebix.monolith.org>

> 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.
> (there are many more 'problem' functions, i'm only listing a few here).
> Any unbounded byte copying is suspect to buffer overruns, and needs to
> be examined and changed.  The drawbacks are obvious, thousands of lines
> of source need to be changed/examined, re-written.

However, it's important to remember that such auditing buys you not
just a secure program but a robust program as well.  So it is
something you would want to do anyway, even if the programs were not
suid.  The security issue just gives it urgency.

Security and robustness really go hand in hand -- they both involve
thinking about the ranges of allowable inputs and responses, and
limiting them so undesirable responses are not produced.
--
Shields, CrossLink.

home help back first fref pref prev next nref lref last post