Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL

[Steffen Dettmer <steffen () dett de>]

* Lamar Owen wrote on Wed, Aug 21, 2002 at 11:02 -0400:
> On Tuesday 20 August 2002 10:28 am, Sir Mordred The Traitor wrote:
> > --[ Solution
> >
> > Do you still running postgresql? ...Can't believe that...
> > If so, execute the following command as a root: "killall -9 postmaster",
> > and wait until the patch will be available.
 [...] 
> Even further, if someone has direct SQL access to your database, they can 
> already do more damage than what this vulnerability addresses.  Specifically 
> DROP TABLE is available to users with direct SQL command line access.  

This is not always true. Usually user have some restricted
access, for instance, are able to do some SELECTs or INSERTs
only.

> Untrusted users should never be given an SQL command line
> interface, and this particular vulnerability requires that sort
> of access.
 [...] 
> fact that a working arbitrary code exploit has not yet been posted.  As noted 
> above, since the postmaster and its backend processes do not run as root, 
> privilege escalation with this bug is not possible.  

Isn't it possible to trigger that bug through another access
interface, for instance Perl::DBI or ODBC? In this case, there
can happend privilege escalation: When for instance a web
frontend is allowed to execute some stored procedures only, and
as per default (AFAIK) to execute such system functions, an
intruder could probably get "postgres" or DBMS superuser
priviledges and by that at least steal or even fake stored data!

This should not depend if an exploit has been posted or not - who
knows, maybe just now some blackhat completed one without making
it public - this should happen sometimes :)

> This is not to say the bug shouldn't be fixed; it of course
> should be fixed.  But it is not so serious that PostgreSQL
> users should simply stop running the postmaster until a patch
> is released.

Yes, this seems a little bit drastic and unusable...

> Some common sense should be applied here -- if you don't use
> the DATE type in a manner that would allow an untrusted user to
> input dates, for instance, you needn't worry about that
> portion.

But in conjunction with other problems, it can cause problems.
Imagine a very restricted web frontend user in a frontend with
bad input validation. Usually the DBMS should do the priviledge
management, and even if an attacker injects DROP TABLE or similar
SQL queries, the DBMS would refuse this with permission denied. I
think, that's what DBMSes are for!

> If you don't allow untrusted SQL cli users, the cash_words and
> repeat bugs shouldn't cause you any problems. By default
> postmaster doesn't accept connections over TCP/IP, making the
> default installation with no network accessible clients not
> vulnerable to a remote exploit.

I don't think that this is a common productive setup. I think,
most PostgreSQL installations accept connections from some
network for at least some clients. Well, personally I never used
a DBMS "with no network accessible clients"...

Furthermore, I think many PostgreSQL linux users use packages
from the distribution vendor, such as SuSE. SuSE's default
installation is to accept network connections, and here in
germany, heaps of installations are SuSE distributions - with
network access to PostgreSQL.

> Having said all that, it would have been nice had a heads up
> been given to the developers.  As far as I know no notification
> of any kind was given, making this an irresponsible advisory.

If I understand this correct, I agree that the developers and
maintainers should have been notificated before.

> The various bugs mentioned are being addressed by the
> developers, who are working to see the best means of fixing and
> distributing fixes for these problems.

I hope it, personally I want to trust PostgreSQL as backend for
web frontends and such, and I want to trust the priviledge
management.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.