Vulnerability Development mailing list archives
Re: Secure coding in C (was Re: Administrivia #4883)
From: marcs () ZNEP COM (Marc Slemko)
Date: Fri, 21 Jan 2000 01:12:16 -0700
On Thu, 20 Jan 2000, Tellier, Brock wrote:
In message <<A HREF="mailto:Pine.LNX.4.03.10001161207550.7428-100000 () brian citynet net">Pine.LNX.4.03.10001161207550.7428-100000 () brian citynet net</A>> Brian Masney writes: : On some UNIX systems, snprintf does not guarentee that it will nul : terminate the string. I know on some older versions of libc5 (sorry, : don't have an exact version), if the buffer you was writing to got to the : max size you passed it, it would stop there without adding the nul. So, : you'll run into problems later on if you pass it to a string : function (like strcpy())snprintf is *DEFINED* to NUL terminate the string. Systems >that don't do this are broken. That's why it is used as widely as it >is.From the Solaris 7 snprintf man page:The snprintf() function is identical to sprintf() with the addition of the argument n, which specifies the size of the buffer referred to by s. The buffer is terminated with the null byte only if space is available. --------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^ Meaning that one shouldn't copy more than bufsize - 1 bytes or risk a bof later on.
Well then it is broken. Well, the man page is at least. The code seems to do the right thing, at least on 2.6: hostname:/tmp$ cat foo.c #include <stdio.h> int main() { char buff[11]; strcpy(buff, "0123456789"); snprintf(buff, 3, "abcdefg"); printf("%s\n", buff); return(0); } hostname:/tmp$ gcc -Wall foo.c -o foo hostname:/tmp$ ./foo ab hostname:/tmp$ But for portable code you need to include your own snprintf anyway if you want to use it, so you may as well use it everywhere. We did in Apache and never looked back. Even more usefully, in Apache it is expanded to allow a psprintf that returns a string dynamically allocated using Apache's pool mechanism, so in places where dynamic allocation is appropriate, it isn't even a consideration. (the "where it is appropriate" bit is, however, important, sine simply switching everything to dynamically allocate memory has obvious DoS potential in some situations)
Current thread:
- Re: things to break.., (continued)
- Re: things to break.. Matt Conover (Jan 24)
- Re: things to break.. John Galt (Jan 24)
- Re: things to break.. Matt Conover (Jan 25)
- Re: things to break.. Simple Nomad (Jan 25)
- Re: things to break.. Jordan Ritter (Jan 25)
- ICQ Pass Cracker. WolF Knox (Jan 26)
- Re: ICQ Pass Cracker. Blue Boar (Jan 26)
- Re: ICQ Pass Cracker. Usman (Jan 26)
- Re: ICQ Pass Cracker. Vladimir Dubrovin (Jan 27)
- Shadow kjkotas (Jan 24)
- Re: Secure coding in C (was Re: Administrivia #4883) Marc Slemko (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Warner Losh (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Blue Boar (Jan 15)
- Re: Secure coding in C (was Re: Administrivia #4883) Brian Kifiak (Jan 16)
- Re: Administrivia #4883 Blue Boar (Jan 15)
- ICQ (Was Re: Administrivia #4883) Imran Ghory (Jan 16)