Re: About CVE-2018-1058 - Mailing list pgsql-general

"Mahongwei (March, ICSL)" <mahongwei@huawei.com> writes:

> Hi
>
>  
>
> From this blog: https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058%3A_Protect_Your_Search_Path
>
>  
>
> Do you think that this is just a mitigation, not a real fix, is there any plan to fix it?
>

I would argue that many possible vulnerabilities are 'mitigated' rather
than 'fixed' and that the guidelines outlined in that blog post are
effective mitigation of this vulnerability and therefore sufficient.
Some would argue passwords are only a mitigation for unauthorised
account access, not a fix. 

The CVE-2018-1058 vulnerability is really an example of a more general issue
associated with environments which use some sort of search path to
determine the location for executable code. Operating systems have a
similar vulnerability with the PATH variable used to determine the
search path for executable files. Basically, if someone can get a user
to add a directory which they have write access to, they can create a
trojan which could be exploited to compromise user security. It is for
this reason that it is generally advised that on Linux systems, add a personal
'bin' or non-standard system directory to the end of your PATH variable rather than the
beginning. For example, consider

export PATH=~/bin:$PATH

compared to

export PATH= $PATH:~/bin

and running the command

sudo some_command

to run "some_command" with increased privileges. If some 'bad actor' managed
to compromise this user (a user who might have lower security controls
than a "high risk" account or be on a host in a more 'permissive'
security zone), they could drop a trojan into the user's bin directory.
Under the first PATH example, the trojan sudo command will be executed
when the user runs sudo, under the second PATH example, the system (and
secure) sudo command will be found before the trojan and executed
safely.

Is the advice to add personal bin directories (or more generally, add
additional 'non-system' directories at the end of the PATH) a mitigation
of this risk? Yes. Is it sufficient protection? Yes. Does it need to be
'fixed'? Probably not and identifying ways that would prevent this issue
are hard to find which don't either significantly limit the
utility of a search path or add a level of inconvenience which
would be difficult to justify. 

In many respects, the search_path variable is not really the issue. The
issue is having a default 'public' schema which can be used by any user
to add functions/procedures that could 'shadow' system functions or
procedures or have a higher precedence in the search path than the
function/procedure the user intends to run.

In general, I will remove the 'public' schema from the default
search_path. If user's want to access objects in that schema, they
either have to explicitly specify the schema or they need to alter their
search_path and add public. I also discourage users from using the
public schema. Generally, I don't prevent users from being able to add
public to their search path or from creating objects in the public
schema (I assume if they go to the length of setting their search_path,
they should know what they are doing). When risk assessments warrant it,
I will remove the ability to create objects in public. 

Applications should put their database objects inside an application
specific schema. Schemas are really just namespaces for databases and
provide similar benefits to namespaces in programming languages. Failing
to take advantage of this facility is like writing BASIC with lots of
GOSUB and GOTOs - full of unexpected side effects, difficult to follow
and hard to manage.

-- 
Tim Cross