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

From Jan Wieck
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id 3D623E7F.C2285FBA@Yahoo.com
Whole thread Raw
In response to Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Responses Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  (Greg Copeland <greg@CopelandConsulting.Net>)
List pgsql-hackers
Justin Clift wrote:
> 
> Hi Mark,
> 
> Mark Pritchard wrote:
> >
> [...]
> > Finally, question the due dilligence process that selects an ISP partner who
> > would leave a database open to the world, even if they run "unbreakable"
> > Oracle :)
> 
> This is the one point of yours I don't feel you've quite got down pat.
> Err... *why* is it safe to leave a HTTP, SSH, IMAP, etc server open to
> the world (configured correctly of course), but somehow fundamentally
> wrong to leave a database server open to the world.  If we've got a
> product without these bugs, there wouldnt be a security vulnerability
> would there?

Because in every system I've seen so far, the application plays a major
role in ensuring the data integrity by implementing at least part of the
business logic. Referential integrity and all the stuff is nice to have
and supports the application developer fighting against concurrency
issues, very hard to solve on the application layer. But the decision if
accountant Victor is permitted to cancel this payment for Hugo is still
up to the application.

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. 


Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Next
From: ngpg@grymmjack.com
Date:
Subject: Re: [SECURITY] DoS attack on backend possible