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, 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Eisentraut Sent: Tuesday, February 13, 2007 6:46 PM To: [EMAIL PROTECTED] Cc: pgsql-general@postgresql.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: [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
