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

From Greg Copeland
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id 1029852318.1562.64.camel@mouse.copelandconsulting.net
Whole thread Raw
In response to Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
On Tue, 2002-08-20 at 08:05, Jan Wieck wrote:
> If you say your users need direct DB access on the SQL interface level,
> I say trash your application because the data it produces isn't worth
> the magnetism on the media. It's not that we ugently need to fix such a
> bug that can only cause a DOS in case someone finds a way to hack
> through the application into the SQL interface. It's that the
> application has to be fixed not to allow that, because even if the
> server wouldn't be crashable, such a hack would end in a disaster.
>

The problem is, the vast majority of these issues are actually caused by
internal resources (people) rather than external "attacks".

The real fear is internal resources DoSing internal resources.  The
reaction on the list is usually to look outward for sources of possible
problems.  That in it self is a problem.  It's well documented the vast
majority (what, 70+%) of these issues actually originate internally.

It is because of these issues that it is often, no longer an issue of
"application this or that", as an application may of been completely
bypassed.

And yes, you can argue all day long that if this happens, you should be
fearing destruction of your data.  While that's true, data can be
restored.  It also requires a different personality type.  Many people
would be willing to DoS a system, however, that doesn't have to mean
they are willing to destroy data.


Regards,
Greg Copeland



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Next
From: Tom Lane
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in