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

From Justin Clift
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id 3D61D16E.3E47E304@postgresql.org
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  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
Hi Mark,

Mark Pritchard wrote:
> 
<snip> 
> 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.
> 
> 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.

What you're saying has a lot of merit, these are important features. 
However, part of our reputation is as being a higher-end, more powerful,
more mature, database offering than other solutions around.

As Tom pointed out, we've already had several releases without getting
rid of this OPAQUE DOS bug, and as pointed out he also really doesn't
have the patience for fixing it (yet).

Was hoping we could get serious bugs fixed sooner rather than later,
otherwise I'm afraid of us just adding more bugs over time until we
start to affect our "having come good" reputation.
> I know that all of my clients have their databases behind several layers of
> firewalls, and taking advantage of a vulnerability such as this remotely is
> extremely difficult.

Totally agreed.  Lots of higher end or corporate places are, and that's
not a bad thing in any way.

For your clients, this particular bugfix doesn't sounds like its
necessary.

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

The schema side of things could be *really* useful for ISPs' for
example, yet a large number of them probably wouldn't be so comfortable
having PostgreSQL available for their clients whilst knowing that these
kinds of DOS bugs exists.  Mentally, it's not a good thing.

Not trying to be a pain here, but instead trying to keep our QA level
up.

:)

Regards and best wishes,

Justin Clift
> Cheers
> 
> Mark

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."  - Indira Gandhi


pgsql-hackers by date:

Previous
From: Mark Pritchard
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Next
From: Neil Conway
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in