>SNIP
>>
>>>As an aside, look at what passes for 'news' in today's UT main page. There's an item about CPU makers putting anti-virus capabilities into chips and quoting the article extract "A buffer overflow essentially overwhelms a computer's defense systems and then inserts a malicious program in memory that the processor subsequently executes.". Obviously the author is satisfied with his/her definition of a "buffer overflow" and obviously the editor knows no better, so here we have it!
>>
>>Sounds like a pretty good laymans explanation to me. Where do you have a problem with how it describes it?
>
>Well, most importantly, a "buffer overflow" itself does NOTHING most often and sometimes causes a crash of an application immediately.

True, it usually will result in a crash.


>When a "buffer overflow" does nothing then there is the possibility that it could be exploited. Someone still has to actually exploit it, and to do that they have to insert code that they can execute. THEN the conditions described by the author might occur.

It could still cause a crash later, it may have just overwritten something that's not currently used, so it might go "unused" for awhile. In any case, the code has to be injected at the time of the overflow.

>I read the original as saying that bad things happen as described every time there is a "buffer overflow" and that is not the case.

I wouldn't say every time from the article was being implied.

>I feel that my understanding (which I admit is inferred from things I've read and deduced on my own too) is a whole lot closer than the article's to reality.

The details would probably be way to complex for a whole lot of people to understand, unless it was simplied as per the article. I still don't see where it's that far "off".