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 ***!
>
> 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
Quantcast