From a117c7a7b62f8978052b69e8e3bfdf8f8099a61d Mon Sep 17 00:00:00 2001 From: Noah Misch Date: Sat, 28 Jul 2018 20:08:01 -0700 Subject: [PATCH] Document security implications of qualified names. Commit 5770172cb0c9df9e6ce27c507b449557e5b45124 documented secure schema usage, and that advice suffices for using unqualified names securely. Document, in typeconv-func primarily, the additional issues that arise with qualified names. Back-patch to 9.3 (all supported versions). Reviewed by Jonathan S. Katz. Discussion: https://postgr.es/m/20180721012446.GA1840594@rfd.leadboat.com --- doc/src/sgml/ddl.sgml | 15 ++-- doc/src/sgml/ref/create_function.sgml | 14 ++-- doc/src/sgml/syntax.sgml | 8 ++ doc/src/sgml/typeconv.sgml | 103 +++++++++++++++++++++++++- doc/src/sgml/xfunc.sgml | 25 +++++-- src/backend/utils/adt/ruleutils.c | 15 ++-- 6 files changed, 147 insertions(+), 33 deletions(-) diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index b4566984c4..07cd7166a4 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -2380,9 +2380,12 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC; using ALTER ROLE user SET search_path = "$user". Everyone retains the ability to create objects in the public schema, but only qualified names will - choose those objects. A user holding the CREATEROLE - privilege can undo this setting and issue arbitrary queries under the - identity of users relying on the setting. If you + choose those objects. While qualified table references are fine, calls + to functions in the public schema will be + unsafe or unreliable. Also, a user holding + the CREATEROLE privilege can undo this setting and + issue arbitrary queries under the identity of users relying on the + setting. If you create functions or extensions in the public schema or grant CREATEROLE to users not warranting this almost-superuser ability, use the first pattern instead. @@ -2393,8 +2396,10 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC; Remove the public schema from search_path in postgresql.conf. The ensuing user experience matches the previous pattern. In addition - to that pattern's implications for CREATEROLE, this - trusts database owners the same way. If you assign + to that pattern's implications for functions + and CREATEROLE, this trusts database owners + like CREATEROLE. If you create functions or + extensions in the public schema or assign the CREATEROLE privilege, CREATEDB privilege or individual database ownership to users not warranting almost-superuser access, use the diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml index c0adb8cf1e..06be04eb5c 100644 --- a/doc/src/sgml/ref/create_function.sgml +++ b/doc/src/sgml/ref/create_function.sgml @@ -545,8 +545,11 @@ CREATE [ OR REPLACE ] FUNCTION as for the command. The string link_symbol is the function's link symbol, that is, the name of the function in the C - language source code. If the link symbol is omitted, it is assumed - to be the same as the name of the SQL function being defined. + language source code. If the link symbol is omitted, it is assumed to + be the same as the name of the SQL function being defined. The C names + of all functions must be different, so you must give overloaded C + functions different C names (for example, use the argument types as + part of the C names). @@ -575,10 +578,9 @@ CREATE [ OR REPLACE ] FUNCTION PostgreSQL allows function overloading; that is, the same name can be used for several different functions so long as they have distinct - input argument types. However, the C names of all functions must be - different, so you must give overloaded C functions different C - names (for example, use the argument types as part of the C - names). + input argument types. Whether or not you use it, this capability entails + security precautions when calling functions in databases where some users + mistrust other users; see . diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml index 018118f6c7..86869bdf8c 100644 --- a/doc/src/sgml/syntax.sgml +++ b/doc/src/sgml/syntax.sgml @@ -1518,6 +1518,12 @@ sqrt(2) Other functions can be added by the user. + + When issuing queries in a database where some users mistrust other users, + observe security precautions from when + writing function calls. + + The arguments can optionally have names attached. See for details. @@ -2590,6 +2596,8 @@ SELECT CASE WHEN min(employees) > 0 its argument values in the same order as they are defined in the function declaration. In named notation, the arguments are matched to the function parameters by name and can be written in any order. + For each notation, also consider the effect of function argument types, + documented in . diff --git a/doc/src/sgml/typeconv.sgml b/doc/src/sgml/typeconv.sgml index ed4be4fcfc..81dba7dacf 100644 --- a/doc/src/sgml/typeconv.sgml +++ b/doc/src/sgml/typeconv.sgml @@ -246,7 +246,19 @@ search path position. Check for an operator accepting exactly the input argument types. If one exists (there can be only one exact match in the set of -operators considered), use it. +operators considered), use it. Lack of an exact match creates a security +hazard when calling, via qualified name + + + + The hazard does not arise with a non-schema-qualified name, because a + search path containing schemas that permit untrusted users to create + objects is not a secure schema usage + pattern. + + +(not typical), any operator found in a schema that permits untrusted users to +create objects. In such situations, cast arguments to force an exact match. @@ -589,6 +601,26 @@ function. In that case the function appearing earlier in the search path is used, or if the two functions are in the same schema, the non-variadic one is preferred. + +This creates a security hazard when calling, via qualified name + + + + The hazard does not arise with a non-schema-qualified name, because a + search path containing schemas that permit untrusted users to create + objects is not a secure schema usage + pattern. + + , +a variadic function found in a schema that permits untrusted users to create +objects. A malicious user can take control and execute arbitrary SQL +functions as though you executed them. Substitute a call bearing +the VARIADIC keyword, which bypasses this hazard. Calls +populating VARIADIC "any" parameters often have no +equivalent formulation containing the VARIADIC keyword. To +issue those calls safely, the function's schema must permit only trusted users +to create objects. + @@ -602,6 +634,15 @@ will not be able to determine which to prefer, and so an ambiguous function call error will result if no better match to the call can be found. + +This creates an availability hazard when calling, via qualified +name, any function found in a +schema that permits untrusted users to create objects. A malicious user can +create a function with the name of an existing function, replicating that +function's parameters and appending novel parameters having default values. +This precludes new calls to the original function. To forestall this hazard, +place functions in schemas that permit only trusted users to create objects. + @@ -610,9 +651,12 @@ found. Check for a function accepting exactly the input argument types. If one exists (there can be only one exact match in the set of -functions considered), use it. -(Cases involving unknown will never find a match at -this step.) +functions considered), use it. Lack of an exact match creates a security +hazard when calling, via qualified +name, a function found in a +schema that permits untrusted users to create objects. In such situations, +cast arguments to force an exact match. (Cases involving unknown +will never find a match at this step.) @@ -750,6 +794,57 @@ SELECT round(4.0, 4); + +Variadic Function Resolution + + + +CREATE FUNCTION public.variadic_example(VARIADIC numeric[]) RETURNS int + LANGUAGE sql AS 'SELECT 1'; +CREATE FUNCTION + + +This function accepts, but does not require, the VARIADIC keyword. It +tolerates both integer and numeric arguments: + + +SELECT public.variadic_example(0), + public.variadic_example(0.0), + public.variadic_example(VARIADIC array[0.0]); + variadic_example | variadic_example | variadic_example +------------------+------------------+------------------ + 1 | 1 | 1 +(1 row) + + +However, the first and second calls will prefer more-specific functions, if +available: + + +CREATE FUNCTION public.variadic_example(numeric) RETURNS int + LANGUAGE sql AS 'SELECT 2'; +CREATE FUNCTION + +CREATE FUNCTION public.variadic_example(int) RETURNS int + LANGUAGE sql AS 'SELECT 3'; +CREATE FUNCTION + +SELECT public.variadic_example(0), + public.variadic_example(0.0), + public.variadic_example(VARIADIC array[0.0]); + variadic_example | variadic_example | variadic_example +------------------+------------------+------------------ + 3 | 2 | 1 +(1 row) + + +Given the default configuration and only the first function existing, the +first and second calls are insecure. Any user could intercept them by +creating the second or third function. By matching the argument type exactly +and using the VARIADIC keyword, the third call is secure. + + + Substring Function Type Resolution diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index bbc3766cc2..3f3d46414c 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -764,8 +764,11 @@ SELECT mleast(ARRAY[10, -1, 5, 4.4]); -- doesn't work Sometimes it is useful to be able to pass an already-constructed array to a variadic function; this is particularly handy when one variadic - function wants to pass on its array parameter to another one. You can - do that by specifying VARIADIC in the call: + function wants to pass on its array parameter to another one. Also, + this is the only secure way to call a variadic function found in a schema + that permits untrusted users to create objects; see + . You can do this by + specifying VARIADIC in the call: SELECT mleast(VARIADIC ARRAY[10, -1, 5, 4.4]); @@ -827,7 +830,10 @@ SELECT mleast(arr => ARRAY[10, -1, 5, 4.4]); parameters after a parameter with a default value have to have default values as well. (Although the use of named argument notation could allow this restriction to be relaxed, it's still enforced so that - positional argument notation works sensibly.) + positional argument notation works sensibly.) Whether or not you use it, + this capability creates a need for precautions when calling functions in + databases where some users mistrust other users; see + . @@ -1399,11 +1405,14 @@ $$ LANGUAGE SQL; More than one function can be defined with the same SQL name, so long as the arguments they take are different. In other words, - function names can be overloaded. When a - query is executed, the server will determine which function to - call from the data types and the number of the provided arguments. - Overloading can also be used to simulate functions with a variable - number of arguments, up to a finite maximum number. + function names can be overloaded. Whether or not + you use it, this capability entails security precautions when calling + functions in databases where some users mistrust other users; see + . When a query is executed, the server + will determine which function to call from the data types and the number + of the provided arguments. Overloading can also be used to simulate + functions with a variable number of arguments, up to a finite maximum + number. diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.c index a38aed2065..5a61d2dac0 100644 --- a/src/backend/utils/adt/ruleutils.c +++ b/src/backend/utils/adt/ruleutils.c @@ -10761,16 +10761,11 @@ generate_function_name(Oid funcid, int nargs, List *argnames, Oid *argtypes, * Determine whether VARIADIC should be printed. We must do this first * since it affects the lookup rules in func_get_detail(). * - * Currently, we always print VARIADIC if the function has a merged - * variadic-array argument. Note that this is always the case for - * functions taking a VARIADIC argument type other than VARIADIC ANY. - * - * In principle, if VARIADIC wasn't originally specified and the array - * actual argument is deconstructable, we could print the array elements - * separately and not print VARIADIC, thus more nearly reproducing the - * original input. For the moment that seems like too much complication - * for the benefit, and anyway we do not know whether VARIADIC was - * originally specified if it's a non-ANY type. + * We always print VARIADIC if the function has a merged variadic-array + * argument. Note that this is always the case for functions taking a + * VARIADIC argument type other than VARIADIC ANY. If we omitted VARIADIC + * and printed the array elements as separate arguments, the call could + * match a newer non-VARIADIC function. */ if (use_variadic_p) { -- 2.40.0