Re: [Lit.] Buffer overruns

blmblm_at_myrealbox.com
Date: 02/12/05 

Date: 12 Feb 2005 21:40:02 GMT

In article <Y9qdnYjnwISuIpHfRVn-iQ@rcn.net>, <jmfbahciv@aol.com> wrote:
>In article <370sshF57ij18U1@individual.net>, blmblm@myrealbox.com wrote:

[ snip ]

>>>>>>>But with one probe all your buffers could overrun.
>>>>>>
>>>>>>Belatedly following up some earlier posts ....
>>>>>>
>>>>>>"Probe"? you must mean something outside my experience/knowledge
>>>>>>here .... Care to elaborate?
>>>>>>
>>>>>The guys here would know how to use a screwdriver; I'd know how
>>>>>to use DDT.
>>>>>
>>>>>There are all kinds of ways to mess up an execution. We'ld
>>>>>do it on purpose just to see if our code caught the error
>>>>>and did something sensible, especially knowing when to stop
>>>>>dead.
>>>>
>>>>So, you're talking about randomly changing something in the
>>>>address space (code or data) of a running program? Yipes.
>>>
>>>Of course. What do you think buffer overruns do?
>>
>>As I said in another reply I just posted, I think we must mean
>>different things by "buffer overrun" (or overflow). I mean the
>>situation in which a program (typically an application / user /
>>non-OS program) tries to put, say, 100 integers into an array that
>>was only declared/allocated to hold 10. Of course this is usually
>>going to lead to bad results, but it can be avoided by writing the
>>program differently.
>
>Sure. Or the pointer gets wrong or the wrong buffer is pointed
>at. All of these are overruns. Not all "overruns" can be fixed
>by making the buffer "big enough".

If I gave the impression that I thought that was a reasonable
general approach to fixing buffer overruns -- not at all!! In many
circumstances (I would say "most" but could be wrong), that just
changes the probability of tripping over the error; it doesn't remove
the error.

My thinking is that before an application developer writes (in C)
"a[i] = 5", he or she should be very sure that the memory address
that corresponds to a[i] is within a's bounds. If there is any
uncertainty, he/she should put in a bounds check and, um, "take
appropriate action" if i is outside the range of acceptable values.
I honestly don't understand why failing to do this is apparently
such a common problem. But I think that part of this topic has
been thoroughly discussed elsethread.

As for the more general case of dereferencing bad pointers, hm,
some of them probably result from other programming errors that
I'm not thinking of right now, but the ones that result from,
say, assuming that malloc will return a non-null pointer and not
checking, well, same thing as above -- if you're trying to write
robust code, you should be checking.

[ snip ]

>>><shrug> It depends on the program. Now do you understand
>>>why we were paid to be extremely paranoid? If you're an
>>>OS and somebody just messed your bits, you have to be
>>>able to deal with it. Think about memories going south
>>>and spraying bits all over core. It is not allowed to
>>>carry the spraying to any disk areas, especially the
>>>boot blocks and SYS: areas.
>>
>>Oh, *hardware* errors .... Yeah. Okay, sorry, I wasn't thinking
>>about those.
>
>Most people don't. :-) That's why us auld farts bat you
>young dudes about the head.

"You young dudes"?

"Sigh!" :-)

As I thought we established in a sociopolitical-commentary thread
last fall (?), I'm neither male nor particularly young, and I've
been doing computing-related stuff more or less full-time since
about 1978. (If you don't remember the sociopolitical thread I'm
referring to -- just as well.) My first few programming classes
used punch cards. What do I have to do to qualify as an "auld
fart"? I sure feel like one some days ....

>Even our bit gods would overlook
>an aspect. Fortunately, we could rely on Murphy's Law to
>embarrass us at the worst possible time but we found our flaws.

:-)

>> ..I think we've had some variant of this conversation
>>before. Maybe I'll get it eventually.
>
>It may be one of your consistent brain farts. In that case,
>you write yourself a large note and paste on your nose or the
>wall or somewhere where you can't ignore the sanity check.
>I had a lot of those cheat sheets.

Yeah. I once read a suggestion in some other newsgroup that every
programmer should maintain "personal bozo list" -- of problems he/she
seemed to trip over regularly, and then any time there was trouble,
the first thing to do is review the list. Similar idea, though
I suppose ideally you'd review your bozo list even before there were
problems ....

[ snip ] 

-- 
| B. L. Massingill
| ObDisclaimer:  I don't speak for my employers; they return the favor.