Re: dump/restore problem due to CVE-2018-1058 (9.5.12) - Mailing list pgsql-general

Thanks for your comprehensive response, Adrian.

On 08/04/18, Adrian Klaver (adrian.klaver@aklaver.com) wrote:
> On 04/08/2018 03:40 AM, Rory Campbell-Lange wrote:
> > On 07/04/18, Adrian Klaver (adrian.klaver@aklaver.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