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

Reply via email to