This is the mail archive of the
mailing list for the glibc project.
Re: Wish for 2002 ...
> Date: Thu, 10 Jan 2002 16:25:49 -0600
> From: Francois Leclerc <firstname.lastname@example.org>
> > Can you name some of these programs?
Have you read the OpenSSH code? Most of the OpenSSH code that uses
these functions has arbitrary limits that really ought to get removed,
as they can cause the programs to misbehave. Once they're removed,
the use of strlcat/strcpy could also be removed.
Here is the first bit of code that I found that doesn't have the
arbitrary limits. It's in auth-skey.c (I used OpenSSH_3.0.2p1):
len = strlen(challenge) + strlen(PROMPT) + 1;
p = xmalloc(len);
p = '\0';
strlcat(p, challenge, len);
strlcat(p, PROMPT, len);
Here, the use of strlcat is redundant: strcat would do just as well,
and would be clearer, smaller, and no doubt faster.
I expect your other examples are similar.
> The commonality of these applications is: They are Network Programs
No -- that's merely an accident. The essential common property of
these applications is that they're poorly written. Typically, they
either have fixed-length buffers that should adjustable, or they are
slower/larger/harder-to-read than they should be.
> I wish to hear from the glibc maintainers and those with the
> respectable "NO." opinion what alternate strcat/strcpy vulnerability
> remediation they propose:
> 1-What is the unit cost of their remediation for
> strcat (b , a);
Nobody in this discussion has presented any real data about costs. I
doubt whether anybody has any hard data. It is hardly fair to require
the skeptics to provide hard data, when the proponents don't have any
hard data either.
> 2-Remediation Process (policies, guidelines and procedures)
> they intend to define and use.
> 3-What remediation tools they intend to use.
It sounds like you favor a analysis process where you simply remove
every instance of strcpy and replace it with strlcpy. This sort of
process can make bean counters happy. But it is not an efficient way
to improve code quality -- on the contrary, it can often make the code