This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [open-source] Re: Wish for 2002



Ben Laurie wrote:
 > Oh please! What's the first mail I read this morning?
 > A post to Bugtraq
 > about a buffer overflow in gzip (which, guess what, is a GNU app) that
 > was incorrectly fixed using strncpy.

My point exactly.  Because strncpy/strncat are easily misused,
mistakes get made.  It's better to provide developers
with easier-to-use, safer alternatives.  For those of you
claiming that the GNU C library shouldn't include strl* because
all GNU tools only use arbitrary length strings... are you prepared
to claim that _no_ GNU tool ever uses strncpy/strncat?
I bet a simple grep will refute that.. Bugtraq is already refuting it.

I'm well aware of the GNU guidance to prefer arbitrary-
length strings, and for general-purpose tools where the
user is not an adversary that's good guidance.  However,
if your input is from an adversary, this can also be
a disadvantage:  the
adversary may use this as a denial-of-service attack
(e.g., constantly send you data until all memory fills up).
This is sometimes worse than the fixed maximum problems
(where an adversary can make it "impossible" to append
to a string). Is a fixed maximum string length better? Sometimes,
and sometimes not. Generally, I prefer the dynamic length
approaches, but sometimes I find they're inappropriate and
strl* is a better approach.

It's better to give the programmer the tools necessary to
easily and securely implement either option.




--- David A. Wheeler
     dwheeler@ida.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]