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


I completely disagree with the claim that the
strlcat/strlcpy functions "don't add much security in practice."
The OpenBSD developers, who have a lot of practical
experience in securing applications, find these functions
to _definitely_ improve security for C code and are rewriting
many programs to use them.  I find them helpful also.
These functions make it simpler to avoid buffer overruns in C,
and buffer overruns are such a problem in C that adding functions
to reduce their likelihood has real value.

There's no need to hash through the advantages of strlcat/strlcpy;
you can see them in this 1999 Usenix paper:
   http://www.openbsd.org/papers/strlcpy-paper.ps
Briefly, they guarantee to NUL-terminate (where the destination
size is non-zero), eliminating a common
mistake (because many C programmers think the standard C routines
guarantee this, and even those who know better forget to
"clean up" after every use of strncat/strncpy).  They also take
the _buffer_ size, not the size left, which eliminates
many off-by-one errors & is simpler
to use (because you don't have to constantly write code to
recalculate space left).  It's faster, too (because the buffer size
is often a compile-time constant).  In short, strlcpy/strlcat
are easier to use securely than the conventional strncpy/strncat,
and I also find them easier to read because less has to be
done to use them correctly (an experience
shared by others).  Like anything else, if you're not used to
them you have to learn their meaning, but they're really simple.

They're no panacea, but if that's the requirement for adding
functions to a library, we can stop writing code now.
They're an incremental aid to a very serious weakness in C.
They force a fixed maximum length, which is sometimes desirable
and sometimes isn't.  But when it's desirable, they help.

Even if _you_ do not find them advantageous, a LOT
of people who worry about application security _do_ find them
advantageous.  It would be far better for the
glibc library to include _built-in_ support for functions
found useful by many, so
that those who are trying to secure programs by using
them can do so easily on glibc-based systems.
They're already supported on Sun Solaris, OpenBSD, and FreeBSD,
and probably others as well, so adding this additional
pair of functions already has strong precedent.



Paul Eggert wrote:

>> Date: Wed, 02 Jan 2002 18:02:33 -0600
>> From: Francois Leclerc <leclerc@austin.sns.slb.com>
> 
> 
>> One of the impediment is the portability of strlcat and strlcpy in glibc.
> 
> 
> This area is controversial.  Personally, I avoid strlcat and strlcpy,
> as I don't think they add much security in practice, and any minor
> advantages they have in that area tend to be outweighed by the fact
> that they make code harder to read and to maintain (which introduces
> its own set of security problems).  I therefore don't recommend their
> use in GNU applications, and I discourage requests to use them in GNU
> applications that I help maintain.
> 
> Some application maintainers disagree with me on this issue, and they
> are free to define and use their own versions of these functions.
> Portable code must define its own strlcat and strlcpy anyway, as these
> functions are not standardized and have different semantics on
> different hosts.  So portability is not an unassailable argument for
> adding them to glibc.
> 
> If a standard like POSIX required us to add these functions to glibc,
> then of course we would add them (perhaps with advice not to use them :-).



--- 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]