Search Postgresql Archives

Re: [ANNOUNCE] Advisory on possibly insecure security definer functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> It has come to the attention of the core team of the PostgreSQL project 
> that insecure programming practice is widespread in SECURITY DEFINER 
> functions.  Many of these functions are exploitable in that they allow 
> users that have the privilege to execute such a function to execute 
> arbitrary code with the privileges of the owner of the function.
> 
> The SECURITY DEFINER property of functions is a special non-default 
> property that causes such functions to be executed with the privileges 
> of their owner rather than with the privileges of the user invoking the 
> function (the default mode, SECURITY INVOKER).  Thus, this mechanism is 
> very similar to the "setuid" mechanism in Unix operating systems.
> 
> Because SQL object references in function code are resolved at run time, 
> any references to SQL objects that are not schema qualified are 
> resolved using the schema search path of the session at run time, which 
> is under the control of the calling user.  By installing functions or 
> operators with appropriate signatures in other schemas, users can then 
> redirect any function or operator call in the function code to 
> implementations of their choice, which, in case of SECURITY DEFINER 
> functions, will still be executed with the function owner privileges.  
> Note that even seemingly innocent invocations of arithmetic operators 
> are affected by this issue, so it is likely that a large fraction of 
> all existing functions are exploitable.
> 
> The proper fix for this problem is to insert explicit SET search_path 
> commands into each affected function to produce a known safe schema 
> search path.  Note that using the default search path, which includes a 
> reference to the "$user" schema, is not safe when unqualified 
> references are intended to be found in the "public" schema and "$user" 
> schemas exist or can be created by other users.  It is also not 
> recommended to rely on rigorously schema-qualifying all function and 
> operator invocations in function source texts, as such measures are 
> likely to induce mistakes and will furthermore make the source code 
> harder to read and maintain.

But if we insert a set schema search_path command in an SQL function,
the caller will be affected by it. Doing reset search_path before
returning to caller might solve some of problems, but it will not
recover caller's special search_path. How do you solve the problem?
--
Tatsuo Ishii
SRA OSS, Inc. Japan


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux