Re: dump/restore problem due to CVE-2018-1058 (9.5.12)
On 04/08/2018 11:01 AM, Rory Campbell-Lange wrote: Thanks for your comprehensive response, Adrian. 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. From other posts that covered similar ground I would say other people would agree. I am guessing the response you will get from those that can make the changes is that would be just delaying the inevitable. You can always ask though:) Thanks again Rory -- Adrian Klaver adrian.kla...@aklaver.com
Re: dump/restore problem due to CVE-2018-1058 (9.5.12)
Thanks for your comprehensive response, Adrian. On 08/04/18, Adrian Klaver (adrian.kla...@aklaver.com) wrote: > On 04/08/2018 03:40 AM, Rory Campbell-Lange wrote: > > On 07/04/18, Adrian Klaver (adrian.kla...@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
Re: dump/restore problem due to CVE-2018-1058 (9.5.12)
On 04/08/2018 03:40 AM, Rory Campbell-Lange wrote: On 07/04/18, Adrian Klaver (adrian.kla...@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) Additionally we sometimes use search_path manipulations + temporary_schema.function to test functions in production environments. Having to qualify the schema of objects seems a retrogressive step, but perhaps our usage is peculiar in this way. AFAIK you can still do that or did I miss something? Yes, you can still do this. Howevever if my function in schema x can still mask the function in schema y I suggest the security issue still exists (as it doesn't refer, at least in the title, to only the 'public' schema): https://nvd.nist.gov/vuln/detail/CVE-2018-1058#vulnCurrentDescriptionTitle A flaw was found in the way Postgresql allowed a user to modify the behavior of a query for other users. An attacker with a user account could use this flaw to execute code with the permissions of superuser in the database. Versions 9.3 through 10 are affected. 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 Background: What is CVE-2018-1058? " The PostgreSQL 7.3 release introduced "schemas," which allowed users to create objects (e.g. tables, functions, etc.) in separate namespaces. When a user creates a database, by default, PostgreSQL creates a schema called public where, by default, all new objects (e.g. tables, functions) are created. ... 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. A PostgreSQL administrator can grant and revoke permissions for a user to both use and/or create objects within a particular schema. Schemas allow users to namespace objects, so objects of the same name can exist in different schemas in the same database. If there are objects with the same name in different schemas and the specific schema/object pair is not specified (i.e. schema.object), PostgreSQL decides which object to use based on the search_path setting. The search_path setting specifies the order the schemas are searched when looking for an object. The default value for search_path is $user,public where $user refers to the name of the user connected (which can be determined by executing SELECT SESSION_USER;). " 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. " More comments below. Also, in a coding environment where object.attribute masking is a feature of the language, as it is in python, this change seems obtuse. My function in schema x can still mask a function in another schema y, so the problem of function masking (if it is a problem) still exists. Are talking Python external or internal to Postgres? I'm talking about how schema.function works in general in postgresql, how useful that is, and how that is similar to other languages (like python). My further suggestion, admittedly from a naive perspective, is that the solution to this problem is inadequate and partial, and that other techniques should be used to solve it, such as making the masking of functions in pg_catalog a new user permission or changing the default search path of postgres superusers to prepend pg_catalog. 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.
Re: dump/restore problem due to CVE-2018-1058 (9.5.12)
On 07/04/18, Adrian Klaver (adrian.kla...@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) > > > > > Additionally we sometimes use search_path manipulations + > > temporary_schema.function to test functions in production environments. > > Having to qualify the schema of objects seems a retrogressive step, but > > perhaps our usage is peculiar in this way. > > AFAIK you can still do that or did I miss something? Yes, you can still do this. Howevever if my function in schema x can still mask the function in schema y I suggest the security issue still exists (as it doesn't refer, at least in the title, to only the 'public' schema): https://nvd.nist.gov/vuln/detail/CVE-2018-1058#vulnCurrentDescriptionTitle A flaw was found in the way Postgresql allowed a user to modify the behavior of a query for other users. An attacker with a user account could use this flaw to execute code with the permissions of superuser in the database. Versions 9.3 through 10 are affected. So if in my database the default search path is x, y, z this "flaw" still exists. > > Also, in a coding environment where object.attribute masking is a > > feature of the language, as it is in python, this change seems obtuse. > > My function in schema x can still mask a function in another schema y, > > so the problem of function masking (if it is a problem) still exists. > > Are talking Python external or internal to Postgres? I'm talking about how schema.function works in general in postgresql, how useful that is, and how that is similar to other languages (like python). My further suggestion, admittedly from a naive perspective, is that the solution to this problem is inadequate and partial, and that other techniques should be used to solve it, such as making the masking of functions in pg_catalog a new user permission or changing the default search path of postgres superusers to prepend pg_catalog. 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. Thanks very much for your comments Rory
Re: dump/restore problem due to CVE-2018-1058 (9.5.12)
On 04/07/2018 12:27 PM, Rory Campbell-Lange wrote:
Hi
Following an upgrade to 9.5.12, we cannot restore some of our databases
due to a schema qualification issue introduced in the new postgres
version of pg_dump.
Specifically, the problem line is the addition of :
SELECT pg_catalog.set_config('search_path', '', false);
to the header of the pg_dump output.
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.
(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)
Additionally we sometimes use search_path manipulations +
temporary_schema.function to test functions in production environments.
Having to qualify the schema of objects seems a retrogressive step, but
perhaps our usage is peculiar in this way.
AFAIK you can still do that or did I miss something?
Also, in a coding environment where object.attribute masking is a
feature of the language, as it is in python, this change seems obtuse.
My function in schema x can still mask a function in another schema y,
so the problem of function masking (if it is a problem) still exists.
Are talking Python external or internal to Postgres?
If internal, then plpythonu is an untrusted language and can only be
used by a superuser. If you are a superuser then there is host of other
things you could do to compromise security as well.
Thanks for any comments.
Regards
Rory
--
Adrian Klaver
adrian.kla...@aklaver.com
