On Tuesday 20 August 2002 11:28 am, Tom Lane wrote:
> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> > But going back to the idea that it seems that the only problem being
> > publicised in the 'outside world' is the cash_out(2) version can we
> > not do the restriction on acceptable input type in order to claim that
> > the fix?
> Basically, we've used "opaque" as a substitute for accurate type
> declarations; that's got to stop.
Umm, but what about the reply buffer overrun advisory? I've read this whole
thread, and the reply advisory (AFAICT, unless I've just hit delete too
quickly) has NOT been addressed. Let's repeat the salient portion of Florian
Weimer's message:
> 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.)
In the DATE parser, not money. Not cash_out. Where do we stand on the DATE
overrun, if one actually exists? If it exists, can it be exploited by a bad
date entry on someone's web form or other client application? If it's not
exploitable, then it lessens the impact -- but it is irresponsible to assume
that just because we can't find a way to exploit it that no one else can.
Now it's possible I just hit delete too quickly; but it's also possible that
everyone has just assumed that this was the cash_out problem and has started
hashing on that. Although this reply advisory hasn't been out as long as the
original one, which WAS cash_words.
If there is indeed an exploitable overrun in the DATE parser, then I believe
we should issue a 7.2.2 to fix this problem. I know that MANY people will be
using 7.2.x for quite awhile, as they won't want to make a MAJOR database
upgrade (which is not painless thanks to the need to use 7.3's pg_dump for
things). If the upgrade was painless, I'd agree that 7.3 is the solution --
but a real security fix shouldn't wait for 7.3. But I'm holding judgment on
a proven exploit. A proven exploit will change my mind to say 'we need a
7.2.2 NOW that fixes this overrun.'
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
