Re: lynx-dev Lynx buffer mismanagement

[Bela Lubkin]

Theo de Raadt wrote:

> > 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 hoped to leverage work you had already done.  Any code you could
specifically point out as having a problem, I would save a bit of
initial evaluation.  I also hoped to provide seed information for other
people who might attack the problem.

Lynx is developed by a loose team of people with various skills.  No one
person "speaks for Lynx".  So when one, or even 3 or 4 people respond to
you saying "we don't see a problem", that doesn't mean that the Lynx
development team as a whole "doesn't see a problem".

> > 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.

I say it is.  gets() interacts so directly with the user, there's almost
a 100% chance that it's exploitable.  With the other functions, there's
a good chance that any particular instance is safe.  There are plenty of
statements like  `sprintf(buffer, "fixed string");'  in Lynx, where
buffer[] is of sufficient size.

> > 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.

You may crow about that, but I feel that the OpenBSD team is also
somewhat culpable.  When you fixed it, did you openly publish that patch
as a security fix?  You cannot reasonably expect everyone to pick up
every bit of code changed by the OpenBSD team.  Some of the changes have
nothing to do with security or anything else that would interest anyone
but you -- things that are OpenBSD environment-specific.

I think OpenBSD is doing great work on security flaws.  But I wish you
would make it part of your development practice to automatically publish
those security fixes for use by other OS authors.  Holding them close to
the chest is ego-boosting because you can say "we have the most secure
OS".  I'm asking you to get that ego boost a different way: "lots of
OSes are more secure because of the great research we've done".

>Bela<