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

2007-06-07 Thread Coffin, Ronald
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: [EMAIL PROTECTED] Phone: 305 237-1054 Fax: 305 237-1531 Please Note: Due to Florida's very broad public records law,

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

2007-02-18 Thread Karsten Hilbert
On Sat, Feb 17, 2007 at 11:31:19AM -0700, Michael Fuhr wrote: If you schema-qualify objects instead of setting search_path then don't forget about operators. I knew I had missed something. SELECT col FROM schemaname.tablename WHERE othercol operator(pg_catalog.=)

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

2007-02-17 Thread Karsten Hilbert
On Sat, Feb 17, 2007 at 01:26:34PM +0900, Tatsuo Ishii wrote: 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

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

2007-02-17 Thread Michael Fuhr
On Sat, Feb 17, 2007 at 03:15:25PM +0100, Karsten Hilbert wrote: On Sat, Feb 17, 2007 at 01:26:34PM +0900, Tatsuo Ishii wrote: 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

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

2007-02-16 Thread Tatsuo Ishii
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

[GENERAL] [ANNOUNCE] Advisory on possibly insecure security definer functions

2007-02-14 Thread Peter Eisentraut
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

[GENERAL] [ANNOUNCE] Advisory on possibly insecure security definer functions

2007-02-14 Thread Peter Eisentraut
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

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

2007-02-14 Thread Kenneth Downs
Peter Eisentraut 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

[GENERAL] [ANNOUNCE] Advisory on possibly insecure security definer functions

2007-02-13 Thread Peter Eisentraut
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

[GENERAL] [ANNOUNCE] Advisory on possibly insecure security definer functions

2007-02-13 Thread Peter Eisentraut
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