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)
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@xxxxxxxxxxx
