Advisory on possibly insecure security definer functions

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.

[english version below]

Drodzy Państwo!

niniejsza wiadomość jest automatycznym potwierdzeniem otrzymania
zgłoszenia w Az.pl, na które prosimy nie odpowiadać.

Uprzejmie dziękujemy za wysłane zgłoszenie i pragniemy zapewnić,
że każde z Państwa zgłoszeń zostanie rozpatrzone z należyta starannością.
Państwa zgłoszeniu został nadany numer:
INO-38939-552
którego prosimy nie kasować z tematu wiadomości.

Powyższy numer pozwoli na zachowanie ciągłości korespondecji i zapobieżenie
pomyłkom komunikacyjnym pomiędzy Państwem a naszą firmą.
W trosce o Państwa cenny czas, odpowiedź na zgłoszenie zostanie wysłana
najpóźniej w ciągu 10 godzin roboczych.

W celu sprawdzenia statusu oraz historii zgłoszenia proszę wejść na stronę
http://support.az.pl. Aby sprawdzić status zgłoszenia konieczna jest prosta
rejestracja.
Odpowiedzi na najczęściej zadawane pytania moga Państwo znaleźć pod adresem
http://www.az.pl/faq.action
Cenne wskazówki oraz pomoc dotyczące panelu DirectAdmin znajdują się na
stronie http://pomoc.az.pl
Zachęcamy rownież do odwiedzania naszej strony http://www.az.pl

This e-mail is an automatic confirmation from our mailing system. Please do not response for it.
Your e-mail has got number: INO-38939-552. During contacting with Az.pl please use this number. We will answer in 10 working hours.
You can check Your e-mail application on: http://support.az.pl.
Help You can find on: http://www.site-helper.com/ and FAQ on: http://www.az.pl/faq.action.
Please visit also our website: www.az.pl.

On 2/13/07, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> 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.

Could you clarify what functions are going to get an explicit 'set
search_path'? Will this change the behavior of any userland
functions?

merlin

Am Mittwoch, 14. Februar 2007 16:31 schrieb Merlin Moncure:
> Could you clarify what functions are going to get an explicit 'set
> search_path'? Will this change the behavior of any userland
> functions?

Nothing is going to "get" anything. You have to fix all affected functions
yourself.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Wed, 14 Feb 2007, Peter Eisentraut wrote:

> 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
> [snip]
> 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.

This fix is not enough in certain common configurations. I've sent a
proof of concept to security<at>postgresql.org, but I won't disclose
it before I'm allowed to by security team.

Regards
Tometzky
--
...although Eating Honey was a very good thing to do, there was a
moment just before you began to eat it which was better than when you
were...
Winnie the Pooh

Thanks for the info

Ron Coffin, Lab Manager
School of Computer and Engineering Technologies
Miami Dade College, North Campus
11380 N.W. 27th Avenue
Miami, Florida 33167
Email: ronald(dot)coffin(at)mdc(dot)edu
Phone: 305 237-1054
Fax: 305 237-1531

Please Note: Due to Florida's very broad public records law, most
written communications to or from College employees regarding College
business are public records, available to the public and media upon
request. Therefore, this e-mail communication may be subject to public
disclosure

-----Original Message-----
From: pgsql-announce-owner(at)postgresql(dot)org
[mailto:pgsql-announce-owner(at)postgresql(dot)org] On Behalf Of Peter
Eisentraut
Sent: Tuesday, February 13, 2007 6:46 PM
To: pgsql-announce(at)postgresql(dot)org
Cc: pgsql-general(at)postgresql(dot)org
Subject: [ANNOUNCE] Advisory on possibly insecure security definer
functions

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.

---------------------------(end of broadcast)---------------------------
-To unsubscribe from this list, send an email to:

pgsql-announce-unsubscribe(at)postgresql(dot)org