Skip site navigation (1) Skip section navigation (2)

Advisory on possibly insecure security definer functions

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-announce(at)postgresql(dot)org
Cc: pgsql-general(at)postgresql(dot)org
Subject: Advisory on possibly insecure security definer functions
Date: 2007-02-13 23:45:48
Message-ID: 200702140045.49029.peter_e@gmx.net (view raw or flat)
Thread:
Lists: pgsql-announcepgsql-general
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.

This problem affects all existing PostgreSQL releases since version 7.3.  
Because this situation is a case of poor programming practice in 
combination with a design mistake and inadequate documentation, no 
security releases of PostgreSQL will be made to address this problem at 
this time.  Instead, all users are urged to hastily correct their code 
as described above.  Appropriate technological fixes for this problem 
are being investigated for inclusion with PostgreSQL 8.3.

Responses

pgsql-announce by date

Next:From: Administrator Az.plDate: 2007-02-14 07:00:04
Subject: [ADM #INO-38939-552]: [ANNOUNCE] Advisory on possibly insecure security definer functions
Previous:From: Selena DeckelmannDate: 2007-02-12 22:09:46
Subject: Fwd: [ANNOUNCE] == PostgreSQL Weekly News - February 11 2007 ==

pgsql-general by date

Next:From: John McCawleyDate: 2007-02-14 01:09:26
Subject: Re: SEQUENCE primary key
Previous:From: vanessaDate: 2007-02-13 21:56:15
Subject: converting a specified year and week into a date

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group