Does anybody know about this?
Regards.
Fernando.
----- Forwarded message from Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE> -----
Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
Precedence: bulk
List-Id: <bugtraq.list-id.securityfocus.com>
List-Post: <mailto:bugtraq@securityfocus.com>
List-Help: <mailto:bugtraq-help@securityfocus.com>
List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
Delivered-To: mailing list bugtraq@securityfocus.com
Delivered-To: moderator for bugtraq@securityfocus.com
To: Sir Mordred The Traitor <mordred@s-mail.com>
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
PostgreSQL
From: Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
Date: Mon, 19 Aug 2002 19:30:52 +0200
In-Reply-To: <3d61116c.98e44ba2@s-mail.com> (Sir Mordred The Traitor's
message of "Mon, 19 Aug 2002 15:40:28 +0000")
User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2
(i386-debian-linux-gnu)
Sir Mordred The Traitor <mordred@s-mail.com> 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
----- End forwarded message -----