Re: lynx-dev Lynx buffer mismanagement

[Theo de Raadt]

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

This indicates a complete lack of understanding as to how OpenBSD
became more secure than other systems:

We didn't search for and specifically fix security problems.  We just
fixed bugs.  We read the source code in every touchy area and fixed
every bug -- security related or not -- that our eyes saw.

We did not test or even consider if the bugs we fixed were exploitable
before our fixes.  Who cares!  I couldn't give a rats ass if they are
exploitable.  Two days later I rebuild my system and the bug is gone.

Let's say we fixed about 15,000 bugs in touchy parts of the system.
Some people have suggested that perhaps we should have posted each of
those patches to all the other groups (I'm sure those groups wouldn't
have wanted that).  But when we make fixes, we don't know if something
is exploitable.  Perhaps 50 of those 15,000 have turned out to be
exploitable later.  We didn't determine exploitability.  People on the
bugtraq mailing list did.

Let me touch on /tmp races for a second: We fixed, I dunno, about 400
perhaps, maybe more.  300 of those can be found by running 'grep
mktemp' on the source tree, the other 100 are just as easy to find.
And yet some people still want specific lists..

We would have looked like complete loonies if we posted messages
somewhere regarding our 35 commits which fixed minor bugs in inetd,
when today, almost two years later, not a single security problem
regarding inetd has come forward yet.  (But one might.. never know,
I've not spent ANY time looking at our inetd to see if any of the bugs
which we fixed matter).

It is not our fault that many bugs turned out to be security problems
later.  We didn't know if they were exploitable.  We just fixed
hundreds of buffer overflows, races, protocol weaknesses, and well,
golly, look, months or years later someone found out those were
exploitable.

There are no security holes in other operating systems which we have
fixed and are "holding close to our chest".  If it hasn't been
published on bugtraq, I am not aware of anything else.

It took about 2 hours to polish the code in the entire lpr/lpd suite
of programs.  The non-OpenBSD person who exploited the lpr buffer
overflow spent 4 days at getting it to work.  The non-OpenBSD person
who exploited the lpd/sendmail problem spend 3 weeks at proving that
it works, and it took at least 3 days for him to just figure out how
to do it.

In both cases, I was very surprised that the problems were
exploitable.  "Wow, it works?  Neato.  Sorry, gotta go back to
auditing libc.."

Our newest source code is updated 6 times a day on anonymous cvs
servers that anyone can look at.  If people (like crackers) want to
investigate some of our bugfixes to see if they were exploitable, they
are _more_ than welcome to do a task which NOONE in our group has ANY
interest in doing.

The other operating system groups have used this source code
repository which we provide and looked at some of our work.  When they
haven't paid attention, and their users have been vulnerable, if blame has
to be laid then it is their fault, not ours.

Some unthinking people think we secured OpenBSD by compiling some list
of security problems that we didn't tell anyone about.  Those people
have completely misunderstand what we did.  I guess you didn't
understand the description of our process at
        www.openbsd.org/security.html.

I'm getting really tired of people who suggest that we have some magic
secret knowledge of how to fix the bugs.  Our difference is simply a
cycle of uncompromising proactive bug hunts.  Like an hour ago three
of us were busy looking looking at mismanagement read/write calls in
httpd.

I am merely suggesting that the lynx developers who don't act
proactively in such an audit are going to look stupid later.  And
there really is no reason to get all cranky when I make such a
suggestion, unless you are really really lazy and don't care about
making your code more perfect.

Certainly, I feel stupid when someone finds a security hole which our
bug hunt didn't find and fix.  But I get a real thrill when we are
ahead of the curve because some team member spent 15 minutes
sanitizing the code of some program...