* 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.
This archive was generated by hypermail 2b30 : Thu Aug 22 2002 - 11:46:43 PDT