Re: [Lit.] Buffer overruns

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

Date: Sat, 29 Jan 2005 04:27:06 GMT

"Trevor L. Jackson, III" <tlj3@comcast.net> wrote in message
news:wJSdnTdPRuhEY2fcRVn-3Q@comcast.com...
> Brian Inglis wrote:
>
>> On Fri, 28 Jan 2005 16:44:05 -0500 in alt.folklore.computers, "Trevor
>> L. Jackson, III" <tlj3@comcast.net> wrote:
>>
>>
>>>infobahn wrote:
>>
>>
>>>>It may indeed be convenient to abdicate responsibility for the
>>>>correctness of one's programs, yes. But there ain't no such thing
>>>>as a free lunch. If you keep ABC, you lose performance. If you
>>>>drop ABC, having written the program as if it were in place, you
>>>>lose safety.
>>>>
>>>>If, on the other hand, you do the checks yourself when they are
>>>>necessary, and not when they are not necessary, then you get the
>>>>best of both worlds.
>>>
>>>Yeah right. Now just how do we tell whether the checks are necessary?
>>>When the writer believes they are. But those are exactly the cases where
>>>he will write "if (p!=NULL) {...}" anyway, so what does that buy you?
>>>
>>>The only safe thing to do is to check all access. And the only way to
>>>obtain a thorough implementation of checks on all access is to have them
>>>installed by the language. Everywhere.
>>
>>
>> ABC for C unfortunately does not do anything to help with the
>> correctness of defective code.
>
> Disagree. It helps detect it during development. And the aftereffect,
> based on the fact that errors tend to cluster, should be a wider
> evaluation of the function/module/component to determine whether that was
> an oops or whether the oops is actually an oh shit!
>
> For correctness stepping on the element past the end of an array is as bad
> as an uncontrolled romp through memory. But from the perspective of
> security the fence post error is no where near as serious as a random
> write or an unlimited block write.

It can be worse.
Consider a buffer you provide for DMA.
Can you trust the hardware?
What happens when the hardware fails and writes beyond the
buffer you provided? What happens when malicious code
reprograms the DMA controller? Perhaps that code is not
part of your application, but was a worm dropped into the OS.

At some level, the only way security can be gauranteed is
if the hardware itself provides the gaurantee.

>> It can only check whether a pointer is within the bounds of an
>> object's storage, it cannot check whether the pointer addresses a
>> currently valid portion of that object. I am thinking here of storage
>> where not all of what is allocated is
>> currently initialized and in use, or linear or circular buffers, where
>> there are address ranges that may be validly read and others that may
>> be validly written to within that storage, possibly none of it at
>> times. The program code *should* be checking that read and write accesses
>> are
>> performed only within the appropriate address ranges, and that should
>> eliminate any possibility of addressing outside bounds. That programs
>> suffer from buffer overflow vulnerabilities is an
>> indication that the program is more seriously defective in not
>> correctly checking or limiting accesses to ensure that only *current*
>> valid address ranges are accessed.
>
> Yes. And the key to resolving that more serious problem is detecting the
> fact that there is a problem at all, even if the apparent seriousness is
> minor or trivial.
>
>>
>> ISTM this is a consequence of rewarding programmers who produce code
>> quickly and cheaply that works well enough to pass a quick, cheap
>> testing effort, but may be vulnerable or fail when subjected to
>> strenuous real world conditions.
>
> Like the criticism of the President, this derives from the tastes of the
> consumers. If the voters cannot tell the difference between scoundrels
> and statesmen we will probably have scoundrels as President.
>
> Similarly, is buyers of software cannot tell the difference between good
> software and bad software companies will hire, reward, and promote
> programmers for generating bad software quickly.
>
> They only do it because _it_works_. 

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

Relevant Pages

  • Re: Secure C library
    ... >> make buffer size decisions more visible, ... >> data about the commonest sources of bugs and security gaffes. ... any number of professional programmers over the past several decades. ... the proposer will come to meetings for a few years to shepherd ...
    (comp.std.c)
  • Re: [Lit.] Buffer overruns
    ... my experience is that programs written in C, except for buffer length ... frequently in C environments as in many other environments. ... null termination convention appeared to encourage programmers ... to believe that length was an attribute of the data pattern ...
    (sci.crypt)
  • Re: Public disclosure of discovered vulnerabilities
    ... > does not have buffer overflows. ... The lack of a general "correctness proof" algorithm has absolutely ... completely free from buffer overruns - and I know this to be correct ... For comparison regarding your "correctness prover", ...
    (sci.crypt)
  • Re: Calling unauthorized code from an authorized address space
    ... Prior to passing the buffer to a work queue for the SRB, ... programmers supply assembler language code to do ... In theory you could interpret compiled assembler code, ... For IBM-MAIN subscribe / signoff / archive access instructions, ...
    (bit.listserv.ibm-main)
  • Re: C++ Bounds Checking
    ... Giles wrote: ... It seems that some C programmers ... a pointer to the beginning of a buffer without also passing the length, ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)