Thread: Is PQfn() insecure or not?

"Programmer's Guide, Client Interfaces, libpq, The Fast-Path Interface"
describes PQfn() and has this alarming remark:
 "This is a trapdoor into system internals and can be a potential  security hole."

Sure this isn't true. PQfn() just lets a frontend call a function which is
also accessible (if maybe not useful) via a SELECT statement, correct?  If
I'm right, we should remove the scary language from the documentation.  If
on the other hand PQfn() is a security hole, could someone post an exploit?

ljb <lbayuk@mindspring.com> writes:
> "Programmer's Guide, Client Interfaces, libpq, The Fast-Path Interface"
> describes PQfn() and has this alarming remark:
>   "This is a trapdoor into system internals and can be a potential
>    security hole."
> Sure this isn't true. PQfn() just lets a frontend call a function which is
> also accessible (if maybe not useful) via a SELECT statement, correct?

The insecure part is not the function call per se (*); it's the fact
that the frontend feeds raw internal-format values to the backend for
the function's parameters.  It'd be fairly trivial to cause a backend
crash by feeding bogus data.  Not sure whether it's possible to do
anything worse than that.

One thing we should think about during the planned protocol redesign for
7.4 is whether to change fastpath to pass and return external-format
values.  This would slow it down marginally, but would make it far safer
and more convenient to use ...

(*) Actually, I just noticed that the fastpath code fails to check whether
the user has permission to call this function, so as of 7.3 that could
be considered a security hole.  It's an easily fixable one, though.
        regards, tom lane

tgl@sss.pgh.pa.us wrote:
> ljb <lbayuk@mindspring.com> writes:
>> "Programmer's Guide, Client Interfaces, libpq, The Fast-Path Interface"
>> describes PQfn() and has this alarming remark:
>>   "This is a trapdoor into system internals and can be a potential
>>    security hole."
>> Sure this isn't true. PQfn() just lets a frontend call a function which is
>> also accessible (if maybe not useful) via a SELECT statement, correct?
> 
> The insecure part is not the function call per se (*); it's the fact
> that the frontend feeds raw internal-format values to the backend for
> the function's parameters.  It'd be fairly trivial to cause a backend
> crash by feeding bogus data.  Not sure whether it's possible to do
> anything worse than that.

Well, if it's 'just' a backend fatal error, that would be OK with me -
you can crash your own backend, big deal. But if it can cause a "panic"
and take out all the backends, that would be more serious, and one could
argue that this means PostgreSQL needs more parameter checking. I think
I'll try and see how much damage I can do.