Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in - Mailing list pgsql-hackers

On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
>
> Most computer virus problems are caused by buffer overrun.  Someone
> decided it wasn't very important.

This is true.  IMO, it is extremely arrogant to ignore a buffer overrun
and announce it can't be exploited.  There is many cases where this
assertion has been proved to be false.  The real risk of overrun is not
what you think can be done with it (or lack there of), rather, it's how
someone else might decide to use it in some obscure manner which you can
not currently fathom or foresee.

> Will you trust your multi-million dollar database to someone who says
> the above?  I think the priorities are upside down.  Any *known*
> buffer-overrun _must_ be repaired, and as quickly as possible.  And

I agree with that too.  When setting priorities, using a scale of 1-10,
10 being highest priority, anything that effects stability or
reliability should always be a 10.  As such, they should always be
repaired even above new wiz-bang features.

IMO, if you don't embrace that rule of thumb, a developer shouldn't be
working on a project where stability and reliability are key components
of the end product.

> potential overruns should be identified.  A grep for memcpy, strcpy,
> gets, etc. should hunt down most of them.  A known buffer overrun should
> fill the designer of a product with abject terror.  And I really mean

Agreed.  It is horribly irresponsible to thumb a nose at such things in
this day and age.

> that, literally.  If you *know* of a buffer overrun, and simply decide
> not to fix it, that sounds very negligent to me.  For a public project
> like PostgreSQL, there is probably very little liability for the
> programmers, but I am thinking of the damage that can be inflicted upon
> potential clients using the database.
>

Not a question of it sounding negligent.  It is negligent.

If quality and stability is not the core developers #1 goal then
expecting people to trust the resulting product is laughable.  Please
tell me why anyone should use a database to maintain important data when
quality and stability is not important to the developers of such a
product.  It's an oxymoron.

Time and time again I've read what basically amounts to, "...if someone
can crash it it's because someone is stupid enough to allow someone to
be able to do it in the first place..."  Maybe you're right.  After all,
if core developers continue to turn a blind eye to such issues, they are
in fact, the facilitators of allowing people to do it to begin with.
That is, they are the ones that allowing people to do it in the first
place.  In short, every time I see that response, I immediately think,
"...now that's the pot calling the kettle black."

At some point in time, you have to stand and say, "the buck stops here."

Now then, after that long rant and rave, since these are known issues, I
don't have a problem with the next release going out as planned.  Once
it does go out, I would certainly hope that the developers would
readjust their priorities and target a bug fix release to immediately
follow.

You know, I've seen many people trash Oracle's "unbreakable" mantra.
I'm sure no one is confused at the fact that it is nothing but a
marketing ploy, however, perhaps there is a culture behind it.  Perhaps
this is their way of saying stability and reliability is very important
to them.  Perhaps their mantra is the rule of thumb outlined above.

Sign,
Greg Copeland