Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id CA+TgmoamVY-WhD23xfY6ZTVX4cZeH4=T0ts8TQ18CuOcH9Uz6g@mail.gmail.com
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Proof of concept: standalone backend with full FE/BE protocol  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Wed, Nov 20, 2013 at 10:13 AM, Peter Eisentraut <peter_e@gmx.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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Next
From: Peter Eisentraut
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol