Re: SLFS

Bill's LFS Login <[email protected]> Tue, 30 Dec 2003 13:06:21 -0500 (EST)
Newsgroups gmane.linux.lfs.security
Message-ID <[email protected]>
On Tue, 30 Dec 2003, Don Smith wrote:

> Archaic wrote:
> > On Thu, Dec 25, 2003 at 09:13:04AM +0000, Spencer Collyer wrote:
> >
> >><snip>

> > That shows that at least one of those functions occurs in every single
> > package LFS installs. I don't think patching every single one is going
> > to be an option, otherwise one would think that some of them would have
> > been fixed by the maintainers by now. :(
> >
>
> Many so-called unsafe functions are not unsafe in the context they are
> used. If, for example, the length of the string to copy has already been
> determined not to exceed the size of the allocated buffer then strcpy()
> is perfectly fine and is more efficient than strncpy(). Patching all
> occurrences would actually be deleterious.

Right on all counts! Unfortunately, "good coding practice" is ignored in
the assessment of risk of vulnerability. The "weaknesses" in these
flagged procedures existed long before the 'net and hacker onslaught.
Programmers were expected to provide code that assured theses
"weaknesses" did not come into play. There is nothing wrong with those
functions *except* that coders can not be relied upon to provide "good
code", thereby turning the "weaknesses" into "vulnerabilities".

A better audit capability (unavailable?) would take into account the
"quality" of the code (e.g. does the code contain checks that prevent
buffer overflows) and then determine if a function was "vulnerable".
Difficult to automate that though.

-- 
NOTE: I'm on a new ISP, if I'm in your address book ...
Bill Maltby
lfsbillATearthlinkDOTnet
Fix line above & use it to mail me direct.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page