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