From: | Rory Campbell-Lange <rory(at)campbell-lange(dot)net> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: dump/restore problem due to CVE-2018-1058 (9.5.12) |
Date: | 2018-04-08 18:01:55 |
Message-ID: | 20180408180154.kk5tayantp2ve2ev@campbell-lange.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks for your comprehensive response, Adrian.
On 08/04/18, Adrian Klaver (adrian(dot)klaver(at)aklaver(dot)com) wrote:
> On 04/08/2018 03:40 AM, Rory Campbell-Lange wrote:
> > On 07/04/18, Adrian Klaver (adrian(dot)klaver(at)aklaver(dot)com) wrote:
> > > > (I'm aware that the reasons behind the change made to the dump format
> > > > due to CVE-2018-1058 are set out here:
> > > > https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path)
> > So if in my database the default search path is x, y, z this "flaw"
> > still exists.
>
> The above refers to the general case and is correct in that regard. The Wiki
> link you shared in your first post details the case that puts you at most
> risk:
>
> https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path
...
> Without adjusting the configuration or access control settings, any user
> that can connect to a database can also create objects in the public schema
> for that database.
...
> The Problem: CVE-2018-1058
>
> "
> The problem described in CVE-2018-1058 centers around the default "public"
> schema and how PostgreSQL uses the search_path setting.
> "
>
> Boiled down it means that out of the box Postgres allows any user to create
> objects in the 'public' schema and the default search_path includes that
> schema. This allows an unprivileged user to create a masking function,
> though the ability to mask is dependent on other factors as shown in the
> example in 'The Problem' section above.
>
> You are correct in that this can happen between other schemas as well. The
> difference is that setting up those schemas is done by the DBA not the
> project and so it is up to the DBA to enforce security. What it comes down
> to is that the release was not a fix as much as a heads up:
>
> "The purpose of the release was to address CVE-2018-1058, which describes
> how a user can create like-named objects in different schemas that can
> change the behavior of other users' queries and cause unexpected or
> malicious behavior, also known as a "trojan-horse" attack. Most of this
> release centered around added documentation that described the issue and how
> to take steps to mitigate the impact on PostgreSQL databases. "
Thank you for setting out the rationale behind the changes so clearly.
> > It still isn't clear to me why the output from pg_dump has a search_path
> > set to ''. That seems to be security through obscurity.
>
> I see it more as a way to flag those instances that fail the recommendations
> in the Wiki article e.g. :
>
> "As a result, pg_restore now fails because we have some table constraints
> that use functions which do not use public schema qualified table/column
> references. "
Fair enough. It is however a tedious problem to resolve in a large
code base and it would be cool to have a new "--set-search-path"
option to pg_dump to override it.
Thanks again
Rory
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2018-04-08 18:15:07 | Re: dump/restore problem due to CVE-2018-1058 (9.5.12) |
Previous Message | Adrian Klaver | 2018-04-08 17:59:44 | Re: Conflict between JSON_AGG and COPY |