Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

On Fri, May 24, 2024 at 12:52 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
wrote:

> 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.
>
>
Function call should schema qualify it. That's painful, but it can be
avoided by setting a search path from inside the function. There was some
discussion about setting a search path for a function at [1]. But the last
message there is non-conclusive. We may want to extend it to extensions
such that all the object references in a given extension are resolved using
extension specific search_path.

[1]
https://www.postgresql.org/message-id/2710f56add351a1ed553efb677408e51b060e67c.camel%40j-davis.com

--
Best Wishes,
Ashutosh Bapat