Re: [Lit.] Buffer overruns

From: Hank Oredson (horedson_at_earthlink.net)
Date: 01/31/05 

Date: Mon, 31 Jan 2005 16:32:53 GMT

"Anne & Lynn Wheeler" <lynn@garlic.com> wrote in message
news:m3fz0hobjs.fsf@lhwlinux.garlic.com...
> 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?

In my opinion you have managed to hit the nail on the head here.

Note the many libraries that replace C string operations with
counted length equivalents, and attempt to provide safe
conversions between the two. 

-- 
  ... Hank
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli

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)