Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 2AB03476603 for ; Wed, 1 Jan 2003 16:57:23 -0500 (EST) Received: from news.hub.org (news.hub.org [64.49.215.80]) by postgresql.org (Postfix) with ESMTP id DD5B64764DA for ; Wed, 1 Jan 2003 16:57:13 -0500 (EST) Received: by news.hub.org (Postfix, from userid 8) id C9AF543A9F6; Wed, 1 Jan 2003 16:57:13 -0500 (EST) From: ljb X-Newsgroups: comp.databases.postgresql.interfaces Subject: Re: Is PQfn() insecure or not? Date: Wed, 1 Jan 2003 21:57:13 +0000 (UTC) Organization: Hub.Org Networking Services (http://www.hub.org) Lines: 20 Message-ID: References: <7477.1041448969@sss.pgh.pa.us> X-Complaints-To: usenet@news.hub.org X-No-Archive: yes User-Agent: slrn/0.9.7.3 (Linux) To: pgsql-interfaces@postgresql.org X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200301/2 X-Sequence-Number: 3502 tgl@sss.pgh.pa.us wrote: > ljb 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.