73585 2002-08-21 02:59 /48 rader/ Sir Mordred The Traitor <mordred@s-mail.com>
Importerad: 2002-08-21 02:59 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1186>
Ärende: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
------------------------------------------------------------
//@(#)Mordred Labs advisory 0x0003
Release data: 20/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: all versions
Risk: high
--[ Description:
...PostgreSQL is a sophisticated Object-Relational DBMS,
supporting almost all SQL constructs, including subselects,
transactions, and user-defined types and functions. It is the
most advanced open-source database available anywhere...blah...blah...
For more info check out this link:
http://www.postgresql.org/idocs/index.php?preface.html#INTRO-WHATIS
There exists a heap buffer overflow in a repeat(text, integer)
function, which allows an attacker to execute malicious code.
--[ Details:
Upon invoking a repeat() function, a
src/backend/utils/adt/oracle_compat.c::repeat() function
will gets called which suffers from a buffer overflow.
--[ How to reproduce:
psql> select repeat('xxx',1431655765);
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
--[ 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.
________________________________________________________________________
This letter has been delivered unencrypted. We'd like to remind you
that the full protection of e-mail correspondence is provided by
S-mail encryption mechanisms if only both, Sender and Recipient use
S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en
(73585) /Sir Mordred The Traitor <mordred@s-mail.com>/(Ombruten)
73586 2002-08-21 05:54 /64 rader/ Sir Mordred The Traitor <mordred@s-mail.com>
Importerad: 2002-08-21 05:54 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1187>
Ärende: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL.
------------------------------------------------------------
//@(#) Mordred Labs advisory 0x0004
Release data: 20/08/02
Name: Two buffer overflows in PostgreSQL
Versions affected: all versions
Conditions: multibyte support
Risk: average
--[ Description:
I guess all of you already hear about the PostgreSQL.
If not, try to visit
http://www.postgresql.org/idocs/index.php?preface.html#INTRO-WHATIS.
There are two buffer overflows in
src/backend/utils/adt/oracle_compat.c. 1) lpad(text, integer, text)
function 2) rpad(text, integer, text) function
--[ Details:
The code for this functions is
src/backend/utils/adt/oracle_compat.c::lpad() and
src/backend/utils/adt/oracle_compat.c::rpad() respectively.
The code suffers from a buffer overflow (of course).
--[ How to reproduce:
shell> pgsql template1 postgres
template1=# select version();
version
-----------------------------------------------------------
PostgreSQL 7.2 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)
template1=# create database my_db with encoding='UNICODE';
CREATE DATABASE
template1# \c my_db
You are now connected to database my_db.
my_db=# select lpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy');
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#
The same for rpad() function.
The vulnerable encodings are: EUC_JP, EUC_CN, EUC_KR, EUC_TW, UNICODE,
MULE_INTERNAL.
--[ Solution
Secure coding of web applications, input validation checks...etc...
________________________________________________________________________
This letter has been delivered unencrypted. We'd like to remind you
that the full protection of e-mail correspondence is provided by
S-mail encryption mechanisms if only both, Sender and Recipient use
S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en
(73586) /Sir Mordred The Traitor <mordred@s-mail.com>/(Ombruten)
73659 2002-08-21 22:18 /48 rader/ Lamar Owen <lamar.owen@wgcr.org>
Importerad: 2002-08-21 22:18 av Brevbäraren
Extern mottagare: Sir Mordred The Traitor <mordred@s-mail.com>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1200>
Ärende: Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
------------------------------------------------------------
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.
This is irresponsible advice, as one should never kill -9 postmaster.
Furthermore, postmaster doesn't run as root, thus this vulnerability
cannot be used as a remote root exploit.
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. Untrusted users should never be given an SQL
command line interface, and this particular vulnerability requires
that sort of access.
The datetime parser overrun is more serious, and has been fixed for
the upcoming 7.3 beta cycle. Backpatching of the fix is being
performed now; it remains to be seen how the fix for 7.2.x will be
distributed. Of note is the 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.
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. 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. 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.
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. There have
been an increasing number of these of late, unfortunately.
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.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
(73659) /Lamar Owen <lamar.owen@wgcr.org>/(Ombruten)
73730 2002-08-22 20:46 /96 rader/ Steffen Dettmer <steffen@dett.de>
Importerad: 2002-08-22 20:46 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: steffen@dett.de
Mottagare: Bugtraq (import) <1214>
Ärende: Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
------------------------------------------------------------
* 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.
(73730) /Steffen Dettmer <steffen@dett.de>/---------
73845 2002-08-24 20:05 /43 rader/ Lamar Owen <lamar.owen@wgcr.org>
Importerad: 2002-08-24 20:05 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1248>
Ärende: Fwd: [GENERAL] PostgreSQL 7.2.2: Security Release
------------------------------------------------------------
---------- Forwarded Message ----------
Subject: [GENERAL] PostgreSQL 7.2.2: Security Release Date: Sat, 24
Aug 2002 00:22:17 -0300 (ADT) From: "Marc G. Fournier"
<scrappy@hub.org> To: pgsql-announce@postgresql.org Cc:
freebsd-databases@freebsd.org, <pgsql-general@postgresql.org>, Vince
Vielhaber <vev@michvhf.com>
Due to recent security vulnerabilities reported on BugTraq, concerning
several buffer overruns found in PostgreSQL, the PostgreSQL Global
Development Team today released v7.2.2 of PostgreSQL that fixes these
vulnerabilities.
The following buffer overruns have been identified and addressed:
... in handling long datetime input
... in repeat()
... in lpad() and rpad() with multibyte
... in SET TIME ZONE and TZ env var
Although v7.2.2 is a purely plug-n-play upgrade from v7.2.1,
requiring no dump-n-reload of the database, it should be noted that
these vulnerabilities are only critical on "open" or "shared"
systems, as they require the ability to be able to connect to the
database before they can be exploited.
The latest release is available at:
ftp://ftp.postgresql.org/pub/sources/v7.2.2
As well as at appropriate mirror sites.
Please report any bugs/problems with this release to:
pgsql-bugs@postgresql.org
Marc G. Fournier
Co-ordinator
PostgreSQL Global Development Group
(73845) /Lamar Owen <lamar.owen@wgcr.org>/(Ombruten)