Thread: [Fwd: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL]

I thought I would throw this bugtraq post into the mix...

--
David Stanaway
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