Re: [Lit.] Buffer overruns

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 01/31/05 

Date: Mon, 31 Jan 2005 08:36:39 -0700

Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
> As has been pointed out, C strings are unrelated to C buffer overflow
> vulnerabilities, where explicit length checks are required, but have
> obviously been omitted by the programmers.

in various copy scenarios .... from a string to an empty buffer, there
is a infrastructure source length available based on nul-terminated,
data-pattern based length paradigm ... however there is no
infrastructure target length available.

there are other PL environments where there are both infrastructure
source lengths and infrastrcture target lengths ... and the
infrastructure utilizes both the source length and the target length
in copy operations. these environments tend to have much lower
incidence of buffer overflow ... because the standard copy operations
have both source length and target length ... even when the programmer
has forgotten to do explicit length checks.

in assembler language environments i've studied ... there has been
some significant number of failures because the programmer has failed
to do sufficient register content management. this is a failure mode
that almost doesn't exist in any of the standard programming
languages.

two long ago and far away bits of information

1) the choice of infrastructure nul-terminated strings for length
paradigm was explicitly chosen because it saved on bytes in the
representation and possibly registers and instructions in generated
code (as compared to a infrastructure length paradigm using pointer
plus explicit length)

2) environments that have a single and consistent paradigm across
multiplicity of different constructs tend to have people making
fewer mistakes

my observations have been that

1) it is possible to apply the nul-terminated string paradigm to areas of
storage containing defined data patterns ... while it isn't very
practical to apply nul-terminated string paradigm to areas of storage
that lack any defined data pattern (like an empty buffer).

2) in many other programming languages that have chosen pointer+length
based length paradigm for use in infrastructure storage length
definitions, they have applied the same, consistent paradigm to both
areas of storage with defined data patterns (like strings) as well as
areas of storage that don't have defined data patterns (like empty
buffers). these environments tend to have much lower incident of
buffer overflow and much lower incident of buffer overflow attacks. A
specific example is that in these environments, a copy operation of
some string to an empty buffer, the infrastructure has determinable
lengths (and tends to make use of them) for both the source data area
and the target data area (whether or not they've been explicitly
provided by the programmer).

so a hypothetical question ... did the explicit choice of a
data-pattern based length paradigm (in the C language environment
which only supports strings) inhibit the development of a
infrastrcture length paradigm that applied to areas of storage w/o
defined data patterns (like buffers). this is compared to other
programming environments which have a infrastructure length paradigm
that is consistant and uniform applicable to all kinds of storage
areas (strings and buffers).

Or conversely, if the explicit C decision had been to choose a
pointer+length representation for strings ... would that paradigm
implementation also have naturally extended to all storage areas
(including buffers). If C had a single, consistant infrastrucutre
length paradigm that was applicable to all areas of storage ... and
was in use by basic infrastructure operations ... would C have
frequency of buffer overflow vulnerabilies compareable to other
enviornments? 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... >> As has been pointed out, C strings are unrelated to C buffer overflow ... > is a infrastructure source length available based on nul-terminated, ... > data-pattern based length paradigm ... ...
    (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. ... Languages such as COBOL would automaically pad or truncate fields during ...
    (comp.os.vms)
  • Re: String concatenation function, request for comments.
    ... usefulness, efficiency, and most importantly the correctness of this small piece of code. ... as the responsibility of freeing the memory would be left to the client. ... If the resultant buffer is needed beyond the second call to the function, it can be copied to another buffer at the clients digression. ... If the strings specified for concatenation exceed the buffer available, ...
    (comp.lang.c)
  • Re: String concatenation function, request for comments.
    ... >> left to the client. ... If the resultant buffer is needed beyond the second ... >> If the strings specified for concatenation exceed the buffer available, ... > This demonstrates a fragility of the interface. ...
    (comp.lang.c)
  • Re: [Lit.] Buffer overruns
    ... > People are still dying in automobile crashes. ... there will always be buffer ... furthermore, normal ABC operation is ... dependent on the infrastructure providing indications as to the bounds ...
    (sci.crypt)
Loading