Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Hi All,

We all know that installing an extension typically requires superuser
privileges, which means the database objects it creates are owned by the
superuser.

If the extension creates any SECURITY DEFINER functions, it can introduce
security vulnerabilities. For example, consider an extension that creates
the following functions, outer_func and inner_func, in the schema s1 when
installed:

CREATE OR REPLACE FUNCTION s1.inner_func(data text)
RETURNS void AS $$
BEGIN
INSERT INTO tab1(data_column) VALUES (data);
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION s1.outer_func(data text)
RETURNS void AS $$
BEGIN
PERFORM inner_func(data);
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

If a regular user creates another function with name "inner_func" with the
same signature in the public schema and sets the search path to public, s1,
the function created by the regular user in the public schema takes
precedence when outer_func is called. Since outer_func is marked as
SECURITY DEFINER, the inner_func created by the user in the public schema
is executed with superuser privileges. This allows the execution of any
statements within the function block, leading to potential security issues.

To address this problem, one potential solution is to adjust the function
resolution logic. For instance, if the caller function belongs to a
specific schema, functions in the same schema should be given preference.
Although I haven’t reviewed the feasibility in the code, this is one
possible approach.

Another solution could be to categorize extension-created functions to
avoid duplication. This might not be an ideal solution, but it's another
consideration worth sharing.

Thoughts?

--
With Regards,
Ashutosh Sharma.