Re: [Lit.] Buffer overruns

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 12/09/04 

Date: 09 Dec 2004 00:14:33 -0700

"Douglas A. Gwyn" <DAGwyn@null.net> writes:
> The Y2K problems were entirely unrelated to whether
> terminated strings were used. In fact with self-
> delimiting strings there is less inclination for
> the programmer to allocate a fixed-width field.

I never intended to imply that Y2K issues were related in any way to
null terminated strings. The example I heard was that null terminated
strings conserved some bytes compared to the explicit header length
paradigm ... and that Y2k issues arose from similar issues regarding
conservation bytes.

Using null terminated string might save 1-3 bytes compared to an
explicit length implementation .... using two (or one) digit for year
could conserv 2(-3) bytes compared to an implementation using 4 digits
for years.

In the 60s and at least early 70s, there was a lot more effort to
do implementations that conserved bytes ... potentially at the
expensve of something else

the original statement from
http://www.garlic.com/~lynn/2004q.html#8

wasn't intended to claim that all things might use null terminated
string ... but that null terminated string was (possibly) justified
because it used less storage (conserved 1-3 bytes possibly compared
to explicit buffer header ... where the length of the buffer is
now carried as an explicit attribute of the buffer) ... and that
many of the Y2k problems arose from efforts in the same era attempting
to conserve real storage.

the statements had more to do with trade-offs made in one era with
conserving/optimizing some resource ... could have significant later
repercusions. I would claim that the a lot of the efforts in the 60s
to use two-byte year fields (rather than 4byte) were done to conserve
storage ... and that optimization led to many of the y2k problems.

I would by analogy argue that the performance/conservation trade-off
of using null terminated strings (based on trade-off choice that it
used less storage than explicit length headers) contributes to the
signficant difference in the number of buffer length vulnerabilities
found in standard c language coding ... compared to the
number/frequency of buffer length vulnerabilities found in
infrastructures that utilize buffer headers with explicit length as
standard coding convention

Again, the statement isn't about what the buffer length qfail-safe way
would be to write c language code ... but whether comparing two
default, coding conventions ... one pervasis C coding conventions and
say PLI coding conventions (with explicit lengths attributes carried
with buffers) and the sigificant difference in the number of buffer
length problems ... could the diffence between explicit buffer length
convention compared to the null-termination convention account for most
of the difference

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... > to explicit buffer header ... ... > now carried as an explicit attribute of the buffer) ... ... NULL terminated strings are not a valid ABSTRACTION for buffers. ...
    (sci.crypt)
  • Re: null terminated strings
    ... terminated strings are blamed because they were being used in the programs ... involved with the overrun situation. ... maximum length for that buffer and make sure you don't exceed it. ... So it takes more experienmce and more self discipline to program in C ...
    (comp.os.vms)
  • [PATCH] input: Null-termination of strings returned to userspace
    ... Removes the risk of returning non-null terminated strings ... to userspace in those cases the provided buffer is too small. ...
    (Linux-Kernel)
Quantcast