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

> -----Original Message-----
> From: Neil Conway [mailto:neilc@samurai.com]
> Sent: Monday, August 19, 2002 10:22 PM
> To: Mark Pritchard
> Cc: Justin Clift; Tom Lane; Christopher Kings-Lynne;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001:
> Buffer overflow in
>
>
> Mark Pritchard <mark@tangent.net.au> writes:
> > I believe its been said before, in this forum no less, that
> PostgreSQL
> > should focus on its primary role as an RDBMS and not be
> paranoid about
> > security. I believe it was the thread on SSL connections, and Tom
> > suggested a simple ssh tunnel or vpn.
>
> I'd say the two issues are pretty different. IMHO, buffer
> overruns and similar security problems are just a special
> class of software bug (it's interesting to note that most of
> the buffer overruns have been found in the less-maintained
> parts of the system, like the cash type or contrib/).
> Therefore, the justification for fixing buffer overruns (and
> avoiding them in the first place) is the same as for fixing
> other kinds of bugs: it makes the system more reliable.
>
> On the other hand, adding something like SSL tends to make
> the system more complex (and therefore *less* reliable).
> There may or may not be a pay-off from a user's POV, but it's
> not the clear win that avoiding buffer overruns is, IMHO.
>
> > Of course, lets not leave the door wide open, but perhaps the
> > developer's time would be better spent on features such as
> schemas and
> > replication.
>
> It's probably worth noting that the "barrier to entry" for
> fixing buffer overruns or doing a code audit is much, much
> lower than for implementing advanced features like schemas or
> replication. The main thing that auditing code requires is
> time, rather than coding skill/knowledge.

Most computer virus problems are caused by buffer overrun.  Someone
decided it wasn't very important.

Some computer viruses have caused billions of dollars in damage.  Sounds
important to me.

"Please try our database.  Someday, we hope to close off all the virus
entry points, but right now, we figure it isn't too important."

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