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

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

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
> Rory
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com