"Mahongwei (March, ICSL)" <mahongwei@xxxxxxxxxx> 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
