From: | ljb <lbayuk(at)mindspring(dot)com> |
---|---|
To: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Is PQfn() insecure or not? |
Date: | 2003-01-01 21:57:13 |
Message-ID: | auvo7p$1viu$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
> ljb <lbayuk(at)mindspring(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Vandana Sudheer | 2003-01-02 00:58:56 | api library for windows client(newbie) |
Previous Message | Tom Lane | 2003-01-01 19:22:49 | Re: Is PQfn() insecure or not? |