Forum OpenACS Q&A: Bugtraq: Buffer overflow in PostgreSQL

From: Sir Mordred The Traitor mordred at s-mail.com
Date: Mon Aug 19, 2002  08:40:28 AM US/Pacific
Subject: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
PostgreSQL


// @(#) Mordred Labs Advisory 0x0001

Release data: 19/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: <= 7.2
Risk: average

--[ Description:
PostgreSQL is an advanced object-relational database 
management system
that supports an extended subset of the SQL standard, including
transactions,
foreign keys, subqueries, triggers, user-defined types and 
functions.

There exists a stack based buffer overflow in cash_words() 
function, that
potentially allows an attacker to execute malicious code.

--[ How to reproduce:
psql> select cash_words('-
700000000000000000000000000000');
pgReadData() -- backend closed the channel unexpectedly.
	.... ....
The connection to the server was lost...

--[ Solution:
Upgrade to version 7.2.1.

and a response to this posting:

From: Florian Weimer 
Date: Mon Aug 19, 2002  10:30:52 AM US/Pacific
To: Sir Mordred The Traitor 
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow 
in PostgreSQL


Sir Mordred The Traitor  writes:

--[ How to reproduce:
psql> select cash_words('-
700000000000000000000000000000');
pgReadData() -- backend closed the channel unexpectedly.
	.... ....
The connection to the server was lost...

--[ Solution:
Upgrade to version 7.2.1.

PostgreSQL 7.2.1 has a buffer overflow bug in the date parser 
(which
is invoked each time a string is converted to a datetime object).  
If
a frontend does not perform proper date checking and rejects 
overlong
date strings, a buffer is overwritten by parser.  The string has to
pass some checks of the parser, so it is not immediately 
obvious that
this can be exploited.  Denial of service is possible, though,
especially if the frontend does not automatically reestablish the
database connection. (All connections are affected, not just the 
one
that is issueing the query.)

To my knowledge, the PostgreSQL developers do not think this 
warrants
an additional 7.2.x release.  They expect that users do not trust 
the
PostgreSQL parsers and write input validation checks.  That 
gives me
the creeps---how can I trust a database which manipulates 
complex
in-memory and on-disk data structures to keep my data, if its
developers say I shouldn't rely on a simple thing they wrote, 
such as
a date parser?

A different problem: "select cash_out(2);".  Known for ages, no fix 
in
sight (seems to be a design problem which is not easy to 
resolve).

*sigh*

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/
fw/
RUS-CERT                          fax +49-711-685-5898

Last thing I saw on the pg list, they were changing the number of args to 32, and they were changing the length of identifiers to 128.

Jon, I love that you reply to each and every security related
posting. It makes me feel more secure knowing security-minded
folk are at work here.

Incidentally, I think Bugtraq is pretty much a must-subscribe to
list. Subscribe to it in digest format, and skim it (there is too to
read it all), and it'll make you a paranoid bastard like Jon 😊

Well, Oracle isn't making a special release to fix the fact that one can reliably crash the entire Oracle database server (not just one connection as is the case here) on Solaris if someone connects with a Linux client that uses the OCI.

They're just saying "don't do that".

PG 7.3 will be in beta in about two weeks and final about four weeks later.  It looks like the PG team will have a release out that fixes the problem much earlier than Oracle will have one which fixes theirs.

Note that the PG developers aren't saying they're not fixing it, merely that they're not going through a full release cycle to get out a new PG 7.2 release.

What does this mean in practice?  Instead of waiting a week or two for a PG 7.2 release with the fix  you'll have to wait two or three weeks for a PG 7.3 beta and about 6-7 weeks for PG 7.3 final.

I think there was some discussion about this on pg hackers.  If I remember correctly, it was stated that yes there is a buffer over flow and there was no way to exploit it.  You could not inject malicious code.  It was more of a dos then an exploit.

Let me know if you'd rather not receive this:

From: Sir Mordred The Traitor 
Date: Tue Aug 20, 2002  07:28:49 AM US/Pacific
To: bugtraq@securityfocus.com
Subject: @(#)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.

If you follow his advice:
<blockquote><i>
Do you still running postgresql? ...Can't believe that...
If so, execute the following command as a root: "killall -9
postmaster"</i></blockquote>
you will in all likeliness corrupt your database.  Never kill -KILL your postmaster.
<p>As far as the problems he's been asked to post the bugs to the group so they can fix them before he posts them to bugtraq.  He say he'll cooperate.
<p>As to the actual risk to your systems, I do hope that no one here exposes their database to the outside world on the internet without enabling password protection for the database????
<p>When I run PG on the same server as AOLserver I don't even start postmaster with "-i".
<p>Whether or not these bugs can be turned into exploits is debatable, however if anyone exposes their RDBMS to the outside world without password protection their stupidity isn't debatable at all.
<p>These will all be fixed in PG 7.3 for sure.

You are right of course, a memory lapse as I knew that ;)

if 7.3 follows the typical pg pattern, it will require a dump/import.

it's true that PG's dump still gets things wrong but I've never seen it hose things so badly that it couldn't be loaded w/ manual editing.  It took half a dozen tries to get everything straightened out when I upgraded from 7.1.3 to 7.2.1 but it got there eventually. :)

7.3 will require a dump/initdb/restore cycle from 7.2.x, and you
will need to use the 7.3 pg_dump to dump your 7.2.x database.  Don't
shoot the messenger -- I don't like it any better than anyone else.

Announced August 23.