Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revise the permission checking on user mapping DDL commands.

  1. BUG #14600: Passwords in user mappings leaked by psql \deu+ command

    andrew.wheelwright@familysearch.org — 2017-03-28T05:38:14Z

    The following bug has been logged on the website:

Bug reference:      14600
Logged by:          Andrew Wheelwright
Email address:      andrew.wheelwright@familysearch.org
PostgreSQL version: 9.5.3
Operating system:   CentOS 6.7
Description:        

Scenario:

I'm working with a multi-server scenario where we have several classes of
user.  For the sake of simplicity I'll call one class power_user and the
other standard_user.  Also for the sake of simplicity, imagine the multiple
servers are called Alice, Bob, and Chuck.

The typical daily use case involve our standard users creating a foreign
table on Alice which references another table on Bob, copying said table
(e.g. create table as ...), dropping the foreign table to Bob, manipulating
data in the table on Alice (i.e. modifying millions of records), creating
another foreign table to Chuck, and copying the data from the table on Alice
to the table on Chuck before dropping both the foreign table and the local
table on Alice.

For our standard users to do their work, they must be able to create these
foreign tables (and no, they're not connecting to the same tables on Bob or
Chuck).

Now, the power_user role has more privileges than the standard_user role. 
Specifically, the power_user has grants to other schemas on Alice and Chuck.

 Both the power_user and the standard_user have usage granted on the foreign
servers Bob and Chuck.

The Problem:

If a standard user logs into Alice using command line client, psql, and runs
the command \deu+, the password for both the standard_user and the
power_user will be visible in the displayed user mapping.  The user could
then log out of Alice and log back in as a power_user.  As far as I can
determine, anyone with usage granted on the foreign server can see ALL
passwords for that foreign server's user mappings.

Note: querying the information schema for user mappings does not display
this same security vulnerability.  It seems psql is getting the information
through some other means.

  2. Re: BUG #14600: Passwords in user mappings leaked by psql \deu+ command

    Feike Steenbergen <feikesteenbergen@gmail.com> — 2017-03-29T14:54:03Z

    > If a standard user logs into Alice using command line client, psql, and
runs
> the command \deu+, the password for both the standard_user and the
> power_user will be visible in the displayed user mapping.

\deu+ queries pg_catalog.pg_user_mappings, which itself is a view on top of
pg_user_mapping.

The permissions on pg_user_mapping (the table) seem sane, they do not allow
you
to see the values. The permissions on pg_user_mappings (the view) are too
wide
it seems.

you could - for your current environment - use the following workaround on
all
your databases:

REVOKE SELECT ON pg_user_mappings FROM public;

I do think this needs a fix however, these credentials should not be
visible to
public.

regards,

Feike

  3. Re: BUG #14600: Passwords in user mappings leaked by psql \deu+ command

    Feike Steenbergen <feikesteenbergen@gmail.com> — 2017-03-29T17:53:50Z

    Attached a patch which copies the logic from commit
93a6be63a55a8cd0d73b3fa81eb6a46013a3a974.

In the current implementation we only consider privileges of the foreign
server
in determining whether or not to show the user mapping details. This patch
copies the same logic (and documentation) used in commit
93a6be63a55a8cd0d73b3fa81eb6a46013a3a974 to not always show the user mapping
options.

regards,

Feike

  4. Re: BUG #14600: Passwords in user mappings leaked by psql \deu+ command

    Noah Misch <noah@leadboat.com> — 2017-04-08T19:34:07Z

    On Wed, Mar 29, 2017 at 04:54:03PM +0200, Feike Steenbergen wrote:
> > If a standard user logs into Alice using command line client, psql, and
> runs
> > the command \deu+, the password for both the standard_user and the
> > power_user will be visible in the displayed user mapping.
> 
> \deu+ queries pg_catalog.pg_user_mappings, which itself is a view on top of
> pg_user_mapping.

Thanks for the report; the next back-branch releases will contain a fix.