Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
>> 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 first approximation, every output function for a built-in
pass-by-reference datatype will show this same behavior.  cash_out is
just getting picked on because it was the one mentioned in the first
complaint.  For that matter, every input function for any datatype
has the same problem:regression=# select cash_in(2);server closed the connection unexpectedly

Let's see ... I count 264 standard pg_proc entries that are declared
with one or more "opaque" parameters.  Many but by no means all are I/O
functions.  There are another 13 standard functions declared to return
"opaque".  To plug the hole in a credible fashion we'd need to do
something about every one of these; so belay that last suggestion that
just implementing a "C string" pseudo-type would be enough to be
meaningful.

Right offhand it looks like we'd need at least:"C string" for the I/O functions"internal type" for index access
functions,selectivity, etc"any array" for array_eq and array_dims"any type" for count(*) (and not much else!)"tuple"
forthe return type of trigger functions"void" for the return type of things that return voidnot sure about encoding
conversionfunctions
 

The functions handling internal-type stuff are probably things we don't
want the user calling at all.  As long as we don't declare any of them
to *return* an internal type, there would be no way to construct a
function call that the parser would accept, so that hole would be
plugged with just one pseudo-type; we don't really need to distinguish
which internal type is meant in any one case.  The "any array"
pseudo-type would probably take a special-case kluge in parse_coerce,
but that doesn't seem intolerable.

Anyone see something I missed?  Tatsuo, what exactly should the function
signature really be for all those encoding conversion functions you just
added?
        regards, tom lane