Bugtraq mailing list archives
Re: better snprintf replacement, anyone?
From: deraadt () CVS OPENBSD ORG (Theo de Raadt)
Date: Tue, 22 Jul 1997 00:57:11 -0600
On Sat, 19 Jul 1997, Theo de Raadt wrote:Quite often I find people saying to me "Why do you use snprintf() all over the place to avoid buffer overflows, and not try to use other techniques. Using snprintf() makes it hard for us to port the code to legacy systems."It's still not clear to me why people only suggest snprintf(). I would imagine that there are only a few cases were a program coulnd't pre-determine the length of a string that would be generated by sprintf() and malloc() enough memory to contain it all. Yes, it's a little extra work to strlen() all the variables you're pulling in, but you ensure that you have a large enough buffer, you eliminate the buffer overflow problem, and you don't truncate the string. Is malloc()-ing the memory *that* inefficient? Less efficient than the scanning and parsing snprintf() must do to the format string?
The reason is simple. snprintf is easy to use. Let me ask you a question. If checking the arguments before calling sprintf is so easy, why did only 1 on 20 programs do so? Why did they all overflow? Why were 4 people kept busy for almost a year fixing buffer overflows? Why, perhaps 10 years after buffer overflows became well known, did people persist in not checking the buffer sizes before calling sprintf? Let me give you an example of what you suggest: if (strlen(a) + 1 + 10 + 3 + 1 + 10 + 4*sizeof(long) + 1 + strlen(b) + 1 + strlen(c) + 2 >= sizeof buf); sprintf(buf, "%s %d see %d %lx %s %s\n", a, i, j, p, b, c); else goto bail; /* I really just wanted to truncate the string... */ The reason is simple. If it isn't easy to write secure code, people will not write secure code. And anyways, in 99% of the cases a truncation is desirable, because anything else is an error we don't know how to deal well with. I have run into very few cases where truncation wasn't acceptable behaviour.
Current thread:
- better snprintf replacement, anyone? Theo de Raadt (Jul 19)
- Re: better snprintf replacement, anyone? Steve \ (Jul 21)
- Re: better snprintf replacement, anyone? Manoj Kasichainula (Jul 21)
- Re: better snprintf replacement, anyone? Theo de Raadt (Jul 21)
- Re: better snprintf replacement, anyone? Alan Cox (Jul 22)
- Re: better snprintf replacement, anyone? James Bonfield (Jul 22)
- ld.so vulnerability Aleph One (Jul 22)
- Security hole in exim 1.62: local root exploit Aleph One (Jul 22)
- Re: Security hole in exim 1.62: local root exploit Warner Losh (Jul 22)
- Named Config Files Gus Huber (Jul 22)
- Re: Named Config Files Aveek Datta (Jul 22)
- Re: better snprintf replacement, anyone? Steve \ (Jul 21)
- <Possible follow-ups>
- Re: better snprintf replacement, anyone? Bill Rugolsky Jr. (Jul 22)
- Re: better snprintf replacement, anyone? Casper Dik (Jul 23)
- Re: better snprintf replacement, anyone? der Mouse (Jul 22)