Bugtraq mailing list archives
Re: the purpose of dynamic memory allocation
From: tqbf () secnet com (tqbf () secnet com)
Date: Fri, 6 Mar 1998 03:10:30 -0600
sinster () DARKWATER COM Thu, 5 Mar 1998 14:21:36 -0800
Dynamic allocation only saves memory when your program executes for a short period of time, or your program uses memory in such a way that memory fragmentation is a non issue
This depends in large part on the allocator you use, and minimization of fragmentation is a basic goal of most memory allocator designs. I certainly don't agree with the assertion that fragmentation issues are a reason to discard dynamic memory allocation (although it may justify discarding your current malloc() implementation). A really good introduction to the issues involved in allocator design is "Dynamic Storage Allocation: A Survey and Critical Review", by Wilson et al at UTexas Austin. You can get it online at ftp://ftp.cs.utexas.edu/pub/garbage/allocsrv.ps As a specific counterexample to the argument you're making, compare memory utilization between qmail (a program that relies almost entirely on dynamic memory allocation, though not necessarilly all from malloc()) and Sendmail (a program that relies comparitively heavily on fixed-size buffers). qmail is a long-running program that uses dynamic memory in a variety of different ways; shouldn't it cause far more swapping than Sendmail? Why is qmail so much faster? The security implications involved in this argument are obvious, and the arguments against fixed-size buffers are compelling. Using fixed-size buffers forces you to write significant amounts of code to track resource usage, and when (note choice of words) this code fails, reliability is impacted in a manner that frequently is exploitable by attackers. Using dynamic memory allocation and abstracting the data types used simplifies code and centralizes resource tracking. In any case, I don't think any scientific arguments are being made here about the performance implications of dynamic allocation, and the points that have been made depend very heavily on the types of programs being discussed. The original point that started this thread is that strncpy() is dangerous, and my interpretation of the subsequent discussion is that strncpy() is, as a security solution, inferior to dynamic memory allocation. Amen! Oh, and let's add one more item to the list of "strncpy considered harmful" points: The "count" provided to the counted string functions is of type size_t, which is (on my machines) unsigned. This means that passing strncpy a negative number results in a "count" parameter that effectively means "infinity". I've seen at least one piece of code that had an exploitable overrun because of a coding mistake involving pointer arithmatic that resulted in strncpy() receiving a "count" of -1. ----------------------------------------------------------------------------- Thomas H. Ptacek Secure Networks, Inc. ----------------------------------------------------------------------------- http://www.enteract.com/~tqbf "mmm... sacrilicious"
Current thread:
- the purpose of dynamic memory allocation D. J. Bernstein (Mar 04)
- Re: the purpose of dynamic memory allocation sinster () DARKWATER COM (Mar 05)
- New OpenBSD security web page Theo de Raadt (Mar 06)
- <Possible follow-ups>
- Re: the purpose of dynamic memory allocation tqbf () secnet com (Mar 06)
- Possible Bug in CDE on HP-UX gareth greenaway (Mar 09)
- Re: Possible Bug in CDE on HP-UX Jeremy Brinkley (Mar 10)
- Re: the purpose of dynamic memory allocation David LeBlanc (Mar 10)
- Re: the purpose of dynamic memory allocation Jeffrey Hutzelman (Mar 10)
- Re: the purpose of dynamic memory allocation Alan Cox (Mar 11)
- DoS (and possibly more) on MDaemon for NT/95 Alvaro Martinez Echevarria (Mar 10)
- MDaemon SMTP Server Buffer Overflow's Aleph One (Mar 10)
- Security problem in Slackware. Suman_Saraf (Mar 11)
- Re: Security problem in Slackware. Peter van Dijk (Mar 13)
- /tmp event logger Michal Zalewski (Mar 14)
- Possible Bug in CDE on HP-UX gareth greenaway (Mar 09)