Re: Proof of concept: standalone backend with full FE/BE protocol

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Date: 2013-11-20 20:24:52
Message-ID: CA+TgmoamVY-WhD23xfY6ZTVX4cZeH4=T0ts8TQ18CuOcH9Uz6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 20, 2013 at 10:13 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 11/14/13, 1:41 AM, Amit Kapila wrote:
>> Security Concern
>> -----------------------------
>> If a user can specify libpq connection options, he can now execute
>> any file he wants by passing it as standalone_backend.
>>
>> Method to resolve Security concern
>> --------------------------------------------------------
>> If an application wants to allow these connection parameters to be
>> used, it would need to do PQenableStartServer() first. If it doesn't,
>> those connection parameters will be rejected.
>
> I don't think this really helps. You can't tell with reasonable effort
> or certainty whether a given program is calling PQenableStartServer(),
> so you cannot audit this from the outside. Also, someone could,
> depending on circumstances, dynamically load a module that calls
> PQenableStartServer(), thus circumventing this check.

What?! The complaint is that somebody who only has access to set
connection parameters could cause a server to be started. There's a
tremendous gulf between "I can set the connection string" and "I can
set LD_PRELOAD". If you can set LD_PRELOAD to a value of your choice,
I'm pretty sure you can do things that are far more entertaining than
calling a hypothetical PQenableStartServer() function.

> And maybe before
> long someone will patch up all drivers to call PQenableStartServer()
> automatically, because why shouldn't I be able to run a standalone
> backend from PHP or Ruby? Also, at some point at least, something like
> phpPgAdmin called pg_dump internally, so you could imagine that in
> situations like that, assuming that pg_dump called
> PQenableStartServer(), with a little bit craftiness, you could expose
> the execute-any-file hole through a web server.

The point is that client applications should expose whether or not to
set this function as a command-line switch separate from whatever they
accept in terms of connection strings. So pg_dump should have a flag
called --standalone-server or something like, and it should all
PQenableStartServer() only when that flag is used. So if the user has
a shell script that invokes pg_dump -d "$1", the user cannot contrive
a server. If they write the script as pg_dump --standalone-server -d
"$1", then they can, but by putting that option in there you pretty
much bought the farm. Any program that calls that function
unconditionally while at the same time accepting untrusted user input
will be insecure, but chmod -R u+s /bin is insecure, too. That's why
we don't do that.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-11-20 20:32:05 Re: Proof of concept: standalone backend with full FE/BE protocol
Previous Message Peter Eisentraut 2013-11-20 20:21:21 Re: Proof of concept: standalone backend with full FE/BE protocol