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