OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Vuln-Dev Archives: Re: Secure coding in C (was Re: Administrivi

Re: Secure coding in C (was Re: Administrivia #4883)

Subject: Re: Secure coding in C (was Re: Administrivia #4883)
From: Paul Cardon (paulMOQUIJO.COM)
Date: Sun Jan 16 2000 - 23:16:31 CST

K Martin wrote:

> > > ] char *a = something();
> > > ] char *b = something_else();
> > > ] int len = strlen(a) + strlen(b);
> > > ] char *c = malloc(len + 1) || die("malloc");
> > > ] (void) strcat(strcpy(c, a), b);
>
> I'm partial to strncpy(); strcpy is a known hobgoblin to secure programming.

Too many people blindly accept the idea of "strcpy bad ... strncpy good ...".

They are both fine when used correctly and both bad when used incorrectly. The
problems are that there are subtleties in the interfaces (design
inconsistencies) that lead to common unsafe usage and too many coders who do not
take the time to read and understand the documentation where those gotchas are
evident (laziness). There are also common mistakes in attempts to use strcpy
and strncpy safely by people who *have* read the documentation.

Todd Miller and Theo de Raadt of The OpenBSD Project have developed a potential
solution presented during the Freenix track of the 1999 Usenix Technical
Conference called "strlcpy and strlcat--Consistent, Safe, String Copy and
Concatenation". The PostScript paper and slides are at

    http://www.openbsd.org/papers/strlcpy-paper.ps
    http://www.openbsd.org/papers/strlcpy-slides.ps

while HTML and PDF versions are available to Usenix members at

    http://www.usenix.org/publications/library/proceedings/usenix99/millert.html

The source code and documentation is at

    http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/

in the files strlcat.c strlcpy.c and strlcpy.3

Hopefully the OpenBSD impementation will undergo additional scrutiny and gain
wider usage. Any new code should consider using it. Just remember that
retrofitting old code must be done carefully to avoid introducing other bugs.

-paul

This archive was generated by hypermail 2b27 : Mon Jan 17 2000 - 00:26:43 CST