Re: [ft-devel] cff_get_name_index crash

[David Turner]

> > Really?  Oh well, that sucks.  :)
> 
> If you're interested in this sort of thing, it's probably a good idea to
> read up on the _reason_ why the glibc maintainer won't include them.
> 

I've read it. His argument is the following:

  A - strcpy itself is not buggy or evil, some developers simply don't use
      it safely, for example when they copy strings of unknown lengths into
      fixed-sized buffers.
    
  B - strlcpy is not better because it only prevents buffer overflows, but
      can introduce another bug (silent string truncations, the horror !!)

while A is certainly true, B is completely false for at least two reasons:

 - first of all, strlcpy gets rid of buffer overwrites for good, and these
   are a *very* common bugs that are responsible for a *lot* of security holes
   in all kinds of software; they're the easiest way to trash the stack and
   take hostile control of program execution. 

 - strlcpy and al. are designed to return the size of the original string
   so that you *can* check for string truncation with something like:

      if ( strlcpy( buffer, src, buffer_size ) >= buffer_size )
         // handle truncation

   in some cases, truncation is not even a bug, it's a feature. Meanwhile,
   when silent string truncation is a bug, it is one that is *much* harder
   to exploit, security-wise, especially if you use system-specific buffer
   sizes like those given by PATH_MAX and al.

On a practical point of view, strlcpy is thus a *lot* better than strcpy.
You get rid of buffer overwrites, you can check for truncation, or you
have the choice to ignore it. And if you do, the security consequences are
relatively dim.

Also, Drepper doesn't understand why people are using strcpy in the first
place: it's for damn convenience; and strlcpy is a *lot* more convenient
than his proposed "correct alternative" which amounts to always computing
the size of the input string, and doing the following:

    *((char *) mempcpy(dst, src, n)) = '\0';

Yeah, highly readable and convenient, isn't it ? I didn't write the part
about computing the length of src in 'n', and checking it against the
buffer size (which doesn't appear in the expression), eventually
perform truncation when needed. Don't worry if it's not even part of POSIX
either.


Regards,

- David Turner
- The FreeType Project  (www.freetype.org)