Re: lynx-dev Lynx buffer mismanagement

[Theo de Raadt]

> Not completely.  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.  No code should
EVER overflow a buffer, anywhere, it it crashes.

What more is there to say?

> > I certainly do not have time to do the job that the lynx people should
> > be doing themselves.  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.
> 
> Lynx has a lot of other problems to tackle, such as keeping up with
> evolving WWW standards.  I don't disagree, and I think hardly anyone
> would disagree, once they understood what you're getting at, that these
> things should be fixed.  But they'll only get fixed when someone has
> time and energy to do it, and feels it's higher priority than other
> current issues.

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

> > > do let everyone know exactly where you see room for improvement
> > 
> > ALL OVER THE CODE.  It's horrible; there's probably 400 buffer
> > overflows in lynx of some sort or another, and it's shameful that
> > noone has sat down and tried to improve the code quality before.
> 
> So do you have a list of 400 instances, to give someone a starting
> place?
>
> Before starting to reply I did a quick search and found about 1200 calls
> to sprintf, strcat, and strcpy.

There you go.

> None to gets(), at least.  ;-}

Why is gets any more of an issue than these others?  It isn't.

> Lynx
> also has its own internal functions which might be susceptible to the
> same problems, so it might be even worse than that.  On the other hand I
> could see right away that a good fraction of them were using internally
> generated data that could be "proven" safe.

A 5 minute peek from me spotted lots of places where internal data was
not limited in length either, though.  In any case, it is careful
coding to avoid even those issues by using truncating functions.

> I'm willing to do the line-by-line evaluation (I've done this for other
> areas of Lynx).  So I'm one of the 3 or 4 most likely people to actually
> tackle the problem.  My request for a starting place applies most of all
> to my own probability of tackling it.

You did a grep, you've got a starting point.  I'd like to remind you
all though of the security problem in lpr from a long time ago, or
perhaps for some of you it is a new story.  There was a place where
two functions were passing pointers around and playing *p++ games with
strings.  It was overflowable.  Someone else in another group did a
strcpy cleanup, but missed the *p++ overflows.  Eventually it hit
bugtraq, and we were clean.  We'd just gone that extra little step and
fixed it 8 months before it was shown to be exploitable.