On Tuesday 20 August 2002 11:28 am, Tom Lane wrote: > "Nigel J. Andrews" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
