Re: lynx-dev Lynx buffer mismanagement

[Philip Webb]

980509 Theo de Raadt wrote:
> 980509 Bela Lubkin wrote: 
>> It would still be helpful to provide some examples you noted,
>> because the people you're talking to are less expert
>> at buffer management issues than you.
>> Even if they would like to carry out your wishes,
>> doing so would be easier with a starting point.
> But it's so easy to find them.  I can't believe you want a detailed list
> of the types of buffer overflows that can happen.
> Go through your code, fix all the buffer overflows.
> It's obvious.  Every strcpy, strcat, sprintf,
> and every place where *p++ goes beyond the end of the buffer.
> Just read the code, understand it, and fix it.
> It's horrible; there's probably 400 buffer overflows in lynx
> of some sort or another, and it's shameful noone has sat down
> and tried to improve the code quality before.
> A 5 minute peek from me spotted lots of places
> where internal data was not limited in length.
>> So do you have a list of 400 instances, to give someone a starting place?
 
thanx Bela for giving this character a patient rational reply.

all one can really say to Mr de Raadt is
that he's the first person ever to make any such claim (in my memory):
Lynx has many users & is supported by some pretty good programmers
& no-one has run into security or other problems due to buffer overflows
or at most only very occasionally during the past couple of years.
if he wants to be taken seriously anywhere anytime by anyone,
he must be prepared to back his generalisations with concrete instances:
if any member of lynx-dev is going to listen to him,
he must provide  >= 1  case where there is a potential buffer overflow
which would cause a crash or a security hole;
if he won't do that, it should be clear to everyone that he can't:
we know Lynx very well & it's a pretty reliable product.

> I'll continue to put lynx in the class of "buffer overflow disasters"
> when people ask me for examples at my talks.

it's like someone walking into a store & telling everyone:
"Hey! this stuff's all garbage! why don't you clean the place up?
it's not even safe! i'm going to warn everybody about it".

if Mr de Raadt were to do that with a commercial software product,
he would find himself on the receiving end of a hefty law-suit,
to which he would -- on present evidence -- have no defense.

my main reason for bothering to reply at length to this guy is
to forestall any waste of anyone's valuable time on him,
assuming he continues to refuse to put his data where his mouth is.

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto