Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in - Mailing list pgsql-hackers

From Nigel J. Andrews
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id Pine.LNX.4.21.0208201228560.1042-100000@ponder.fairway2k.co.uk
Whole thread Raw
In response to Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
List pgsql-hackers
On Mon, 19 Aug 2002, Tom Lane wrote:

> Justin Clift <justin@postgresql.org> writes:
> > From the info still around, this looks to mean that the cash_words()
> > problem was fixed, but the cash_out() problem was harder to fix.
> 
> > Tom/Bruce, is that correct?
> 
> The cash_out problem can't really be fixed until we do something about
> subdividing type "opaque" into multiple pseudo-types with more carefully
> defined meanings.  cash_out is declared cash_out(opaque) which does not
> really mean that it accepts any input type ... but one of the several
> meanings of "opaque" is "accepts any type", so the parser doesn't reject
> cash_out(2).
> 
> I'd like to see something done about this fairly soon, but it's not
> happening for 7.3 ...

Does anyone have an idea about what other functions are affected by this?

As a stop gap measure to remove the *known* DoS issue how about changing the
pg_proc entry to restrict input types, i.e. not cash_out(opaque)? cash_words is
already listed as only taking the money type is cash_out really that different?

On a related topic cash_out() is listed in pg_proc as returning an int4 but
doesn't the code clearly show that is incorrect?


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants




pgsql-hackers by date:

Previous
From: Vince Vielhaber
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Next
From: Rod Taylor
Date:
Subject: Re: regression test failures in CVS HEAD