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:

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'

     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:


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

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.

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. "

Thanks very much for your comments

Adrian Klaver

Reply via email to