dss-lfs at cfl.rr.com
Tue Dec 30 10:47:48 PST 2003
Bill's LFS Login wrote:
> On Tue, 30 Dec 2003, Don Smith wrote:
>>>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.
Actually I was talking about things along the lines of composing output
messages from known fixed strings, for example, error message texts.
Doing a strcpy() to place those fixed strings into an output message
poses no threat even though no explicit check on the length of the
string to copy had been done.
This would be extremely hard to automate and requires in-depth knowledge
of a seasoned programmer (I think we agree here).
More information about the hlfs-dev