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

From Mark Pritchard
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id 200208201446.24092.mark@tangent.net.au
Whole thread Raw
In response to Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  (Justin Clift <justin@postgresql.org>)
Responses Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
On Tue, 20 Aug 2002 13:40, Justin Clift wrote:
[snip]
> For example, thinking about something like the various ISP's around who
> host PostgreSQL databases; how much effort would it take to fix the
> vulnerabilities that let someone with remote access, but no ability to
> run a "trusted" language, take out the backend?

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.

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.

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 :)

Cheers

Mark


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: XLogDir
Next
From: Justin Clift
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in