pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedIs PQfn() insecure or not?
3+ messages / 2 participants
[nested] [flat]
* Is PQfn() insecure or not?
@ 2003-01-01 00:40 ljb <lbayuk@mindspring.com>
0 siblings, 1 reply; 3+ messages in thread
From: ljb @ 2003-01-01 00:40 UTC (permalink / raw)
To: pgsql-interfaces
"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?
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Is PQfn() insecure or not?
@ 2003-01-01 19:22 Tom Lane <tgl@sss.pgh.pa.us>
parent: ljb <lbayuk@mindspring.com>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2003-01-01 19:22 UTC (permalink / raw)
To: ljb <lbayuk@mindspring.com>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Is PQfn() insecure or not?
@ 2003-01-01 21:57 ljb <lbayuk@mindspring.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: ljb @ 2003-01-01 21:57 UTC (permalink / raw)
To: pgsql-interfaces
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.
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2003-01-01 21:57 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-01-01 00:40 Is PQfn() insecure or not? ljb <lbayuk@mindspring.com>
2003-01-01 19:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-01-01 21:57 ` ljb <lbayuk@mindspring.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox